Queries at old snapshots return intervals that begin at pin + 1

Example logs: VbesP, a9Uzc, btQdq

zgrep 'ps->andStar' clog-*
for f in `zgrep andStar clog-* | sed 's/:.*//'`; do zgrep 'RO query' $f | tail -n 1; done

VgjfF 14178   Client_Exec     (client.c:403):     RO query BEGIN READ ONLY SNAPSHOTID 50188; SELECT items.id,items.name,items.initial_price,items.max_bid,items.nb_of_bids,items.end_date FROM items,users WHERE items.category=10 AND items.seller=users.id AND users.region=4 AND end_date>=NOW() LIMIT 20 OFFSET 0
VgjfQ 14178   Client_Exec     (client.c:478):     Database status: SELECT VALIDITY 50189 50201

So far, almost all of the examples I've found have been the above
query.  btQdq (clog-21368) also exhibits

bverJ 21368   Client_BeginRO  (client.c:230):     Began cache transaction with pin set {108, *}
bverJ 21368   Client_Exec     (client.c:400):     RO query BEGIN READ ONLY SNAPSHOTID 108; SELECT id FROM users WHERE nickname='user291' AND password='password291'
bverO 21368   Client_Exec     (client.c:475):     Database status: SELECT VALIDITY 1 115
bverR 21368   Client_Exec     (client.c:400):     RO query SELECT * FROM users WHERE users.id=291
bverT 21368   Client_Exec     (client.c:475):     Database status: SELECT VALIDITY 1 115
bverU 21368   Client_Exec     (client.c:400):     RO query SELECT item_id, max(bids.max_bid) AS max_bid FROM bids, items WHERE bids.user_id=291 AND bids.item_id=items.id AND items.end_date>=NOW() GROUP BY item_id
bvere 21368   Client_Exec     (client.c:475):     Database status: SELECT VALIDITY 109 115

Status: resolved

When a pin was removed from the lower bound of the invalidity mask by
ValidityIntervalExclude, the lower bound was set to one greater than
the pin.  It is now set to the pin.  If the transaction immediately
preceding the pinned transaction deleted a tuple, then any query that
would have matched that tuple would have the pin number removed from
the left side of the validity interval, ultimately removing it from
the final interval.