On Oct24, 2014, at 22:50 , Kevin Grittner <kgrittn@ymail.com> wrote:
> I need to spend some more time looking at it, and I have another
> couple things in front of this on my personal TODO list, but I
> think that if we had a row lock which was stronger than current
> SELECT FOR UPDATE behavior, and the delete of a parent row (or
> updated of its referenced key) read the children using it, this
> would be solved. Essentially I'm thinking of something just like
> FOR UPDATE except that a transaction which attempted a concurrent
> UPDATE or DELETE of the row (before the locking transaction ended)
> would error out with some form of serialization failure. I believe
> this would be consistent with the behavior of SELECT FOR UPDATE in
> Oracle, so it would allow a path for those migrating from Oracle to
> maintain their current logic (with a slight change to the FOR
> strength clause).
Hm, I don't believe any form of traditional row-level lock on the
child row can fix this. If you look at the second failure case
(an updated isolation tester spec file which includes comments is
attached), you see that it fails even if you define the FK constraint
as CASCADE instead of RESTRICT. So even a full UPDATE or DELETE
of the child rows doesn't help.
But maybe I miss-understood what you proposed.
best regards,
Florian Pflug