Request for suggestions

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.

Responses

Browse pgsql-hackers by date

  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