| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
|---|---|
| To: | Doug Safreno <doug(at)avinetworks(dot)com> |
| Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-bugs\(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Gregory Cox <gcox(at)avinetworks(dot)com>, Sambit Das <sambit(dot)das(at)avinetworks(dot)com>, Vivek Kalyanaraman <vivek(at)avinetworks(dot)com>, Anand Parthasarathy <anpartha(at)avinetworks(dot)com>, webapp-dev <webapp-dev(at)avinetworks(dot)com> |
| Subject: | Re: Bug: Deferred FKey Check Happening on Double Update, Not Single |
| Date: | 2019-02-15 23:15:25 |
| Message-ID: | 87tvh4k5m5.fsf@news-spur.riddles.org.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
>>>>> "Doug" == Doug Safreno <doug(at)avinetworks(dot)com> writes:
Doug> Hey Sergei,
Doug> Neither transaction touches FK fields - so shouldn't they both
Doug> skip FK trigger check?
The optimization that lets the check be skipped only applies on the
_first_ modification of the row within the transaction. On the second or
subsequent modifications, the code can't easily tell whether the row was
inserted in the current transaction (in which case the optimization must
be skipped) or just modified, so it assumes the worst.
--
Andrew (irc:RhodiumToad)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Doug Safreno | 2019-02-16 00:11:04 | Re: Bug: Deferred FKey Check Happening on Double Update, Not Single |
| Previous Message | Doug Safreno | 2019-02-15 22:35:23 | Re: Bug: Deferred FKey Check Happening on Double Update, Not Single |