| From: | Nick Barnes <nickbarnes01(at)gmail(dot)com> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: FK check implementation |
| Date: | 2014-10-14 03:29:48 |
| Message-ID: | CAG+WGGm+AhDZAJh2zNhd68uxK3Kb822ZYYKS7zPQP_RfPsLW+A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 10/10/2014 10:41 AM, Nick Barnes wrote:
>
>
>> I understand why the FK insert needs to lock on the PK row. But why is
>> the PK delete trying to lock the FK row? If it finds one, won't the
>> delete fail anyway? If it doesn't find one, what is there to lock?
>>
>>
> I would say this has to do with setting DEFERRABLE on a constraint.
>
Any guesses why this might be? I would have thought that by this point,
where we're actually performing the check, anything related to deferring
the check would be behind us.
And even if we do require a lock, why FOR KEY SHARE? As I understand it,
this won't lock the referencing field, which should be the only thing in
the FK relation that we're interested in.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan Neve | 2014-10-14 07:58:16 | Where should I post 3rd party product announcements? |
| Previous Message | Stephen Davies | 2014-10-13 23:53:29 | Re: 9.3 migration issue |