> This should not be considered a problem for repeatable read > transactions because the change in visible rows meet the definition > of phantom reads, which are allowed in repeatable read: "A > transaction re-executes a query returning a set of rows that > satisfy a search condition and finds that the set of rows > satisfying the condition has changed due to another > recently-committed transaction."
Now I'm confused. Isn't the whole point of REPEATABLE READ to provide, well, repeatable reads? Also, note that after the DELETE FROM parent, further SELECTS in the same transaction will use the original snapshot again, und thus will see the conflicting child rows again that were ignored by the RI trigger. But they won't, of course, see the parent row. IOW, transaction A will, after the delete, see a state of the database in which the PK constraint is broken. I don't think that's acceptable in any isolation level. Best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
