On Oct24, 2014, at 19:32 , Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 24, 2014 at 1:28 PM, Florian Pflug <fgp@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
