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