Florian Pflug <f...@phlo.org> wrote: > So in conclusion, the lock avoids raising constraint violation errors in
> a few cases in READ COMMITTED mode. In REPEATABLE READ mode, it converts some > constraint violation errors into serialization failures. Or at least that's > how it looks to me. It doesn't seem like this analysis considers all of the available ON DELETE and ON UPDATE behaviors available. Besides RESTRICT there is CASCADE, SET NULL, SET DEFAULT, and NO ACTION. Some of those require updating the referencing rows. >> And even if the lock serves a purpose, KEY SHARE is an odd choice, since >> the referencing field is, in general, not a "key" in this sense. > > Hm, yeah, that's certainly weird. I don't think I understand that either. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
