Re: Question about RI checks
| От | Nick Barnes |
|---|---|
| Тема | Re: Question about RI checks |
| Дата | |
| Msg-id | CAG+WGGnefBg75Va0zRVvogRe=dqQVq0ahEd6fTRnniqyNwmQXg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Question about RI checks (Kevin Grittner <kgrittn@ymail.com>) |
| Ответы |
Re: Question about RI checks
|
| Список | pgsql-hackers |
On Wed, Oct 22, 2014 at 3:19 AM, Kevin Grittner <kgrittn@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 <kgrittn@ymail.com> wrote:
Florian Pflug <fgp@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
В списке pgsql-hackers по дате отправления: