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. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
