On Oct24, 2014, at 19:32 , Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug <f...@phlo.org> wrote: >> The only other option I see would be so teach the executor to check >> whether *any* snapshot between the transaction's snapshot and a current >> snapshot would see a different set of rows. Simply checking whether both >> the current snapshot and the transaction's snapshot see the same set isn't >> sufficient, per the counter-example in my other mail :-( > > What about doing one scan using SnapshotAny and then testing each > returned row for visibility under both relevant snapshots? See > whether there is any tuple for which they disagree.
See my other mail - testing whether the snapshots agree isn't enough, you'd have to check whether there could have been *any* snapshot taken between the two which would see a different result. Or at least what I currently think - I don't yet have an actual proof at hand that doing this always preserves serializability. But it seems plausible that it does, because it ensures that there is a rather large time frame during which the enforcement query can be placed in a serial schedule without changing its result. This applies only to SERIALIZABLE transactions, though. For REPEATABLE READ, it might be that checking whether the two snapshots agree is sufficient. So a third way forward would be to not skip the SSI logic for RI enforcement queries. Though I fear that, due to the imprecise nature of SIREAD locks, doing so would drive the false positive rate way up for workloads involving lots of parent and child row modifications. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
