Re: [GENERAL] UPDATE column without FK fires other FK triggersconstraint check

Поиск
Список
Период
Сортировка
От Luca Looz
Тема Re: [GENERAL] UPDATE column without FK fires other FK triggersconstraint check
Дата
Msg-id CAHXaXTxO72TwuA6Pg07oQ2iuWKXX8OjWE=BPqFZ7QXDz5htjFw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] UPDATE column without FK fires other FK triggers constraint check  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Thanks for the explanation!
Can these checks be implemented or the data needed is not there and adding it will only add an overhead for the majority of use cases?

2017-07-19 20:42 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Luca Looz <luca.looz92@gmail.com> writes:
> After some tests it seems that this happens when the same row is covered by
> more than 1 update in the same transaction even without any change.
> Is this an expected behavior? Why it happens?

Yes, see comment in RI_FKey_fk_upd_check_required:

             * If the original row was inserted by our own transaction, we
             * must fire the trigger whether or not the keys are equal.  This
             * is because our UPDATE will invalidate the INSERT so that the
             * INSERT RI trigger will not do anything; so we had better do the
             * UPDATE check.  (We could skip this if we knew the INSERT
             * trigger already fired, but there is no easy way to know that.)

Although this is talking about the BEGIN; INSERT; UPDATE; COMMIT case,
the code has no way to tell that apart from BEGIN; UPDATE; UPDATE; COMMIT.

                        regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Evan Martin
Дата:
Сообщение: [GENERAL] Why would log_lock_waits affect a query plan?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Why would log_lock_waits affect a query plan?