From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Request for suggestions |
Date: | 2002-10-09 14:16:12 |
Message-ID: | 20021008095012.L91700-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Sir Mordred The Traitor | 2002-10-09 15:16:24 | Just a thought |
Previous Message | Tom Lane | 2002-10-09 14:14:54 | Re: pgsql 7.2.3 crash |