On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
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.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.
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.
