Re: Locking concurrency: select for update vs update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Streamsoft - Mirek Szajowski <m(dot)szajowski(at)streamsoft(dot)pl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Locking concurrency: select for update vs update
Date: 2016-06-07 13:24:10
Message-ID: 32195.1465305850@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Streamsoft - Mirek Szajowski <m(dot)szajowski(at)streamsoft(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Streamsoft - Mirek Szajowski 2016-06-07 13:26:27 Re: Locking concurrency: select for update vs update
Previous Message Josh Berkus 2016-06-07 13:03:20 Re: array size exceeds the maximum allowed (1073741823) when building a json