On Wed, Oct 22, 2014 at 3:19 AM, Kevin Grittner <kgri...@ymail.com> wrote:
> > 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. > I think the logic in question is specific to RESTRICT and NO ACTION. The other cases don't look like they need to explicitly lock anything; the UPDATE / DELETE itself should take care of that. On Wed, Oct 22, 2014 at 3:19 AM, Kevin Grittner <kgri...@ymail.com> wrote: > 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 >
