Re: Question about RI checks

On Wed, Oct 22, 2014 at 3:19 AM, Kevin Grittner <kgrittn(at)ymail(dot)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 <kgrittn(at)ymail(dot)com> wrote:

> Florian Pflug <fgp(at)phlo(dot)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
>