Request for suggestions
От | Stephan Szabo |
---|---|
Тема | Request for suggestions |
Дата | |
Msg-id | 20021008095012.L91700-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответы |
(Followup) Request for suggestions
|
Список | 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.
В списке pgsql-hackers по дате отправления: