I've been working on kludging a working
for update barrier style lock (*) for reads
using HeapTupleSatisfiesDirty to test
accessibility to make the foreign keys
work better. I'm fairly close to getting
a testable kludge for the fk/noaction cases
for people to check real sequences against
(since I'm using simple examples as I think
of it).
At some point I'm going to want to do
something that's less of a kludge which
might hopefully also let me remove the whole
hack in tqual.c (right now the hack's gotten
worse since I use the value to specify what
kind of check to do). In addition, I'm not
100% sure how to proceed on the
non-noaction/restrict cases, since I'd kind
of want to do a dirty read to find candidate
rows for the update/delete which gets
into having heap_delete fail for example
since the row is invisible. For the lock
above I made a new "for ..." specifier for the
statement to separate the behavior, but I'm
not sure something like that is really a good
idea in practice and I'm a little worried
about changing the logic in heap_delete (etc)
for invisible rows in any case.
So, I'm looking for suggestions on the best
way to proceed or comments that I'm going
about this entirely the wrong way... :)
(*) - It blocks on the transaction which
has a real lock on the row, but does not
itself get a persistent lock on it.
