Re: Locking concurrency: select for update vs update - Mailing list pgsql-performance

From Tom Lane
Subject Re: Locking concurrency: select for update vs update
Date
Msg-id 32195.1465305850@sss.pgh.pa.us
Whole thread Raw
In response to Locking concurrency: select for update vs update  (Streamsoft - Mirek Szajowski <m.szajowski@streamsoft.pl>)
Responses Re: Locking concurrency: select for update vs update
List pgsql-performance
Streamsoft - Mirek Szajowski <m.szajowski@streamsoft.pl> writes:
> Why I can't execute 'select for update' but I can update?

In recent PG versions, the lock held due to having inserted an FK
dependent row effectively only locks the key fields of the parent row.
UPDATE can tell whether you're trying to change the row's key fields,
and it will proceed if you aren't.  SELECT FOR UPDATE has to lock the
whole row (since it must assume you might be intending to change any
fields of the row); so it blocks until the FK lock goes away.

            regards, tom lane


pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: array size exceeds the maximum allowed (1073741823) when building a json
Next
From: Streamsoft - Mirek Szajowski
Date:
Subject: Re: Locking concurrency: select for update vs update