Re: Locking question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Torsten Förtsch <torsten(dot)foertsch(at)gmx(dot)net>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Locking question
Date: 2015-02-26 15:08:05
Message-ID: 31732.1424963285@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= <torsten(dot)foertsch(at)gmx(dot)net> writes:
> given a query like this:

> select *
> from account a
> cross join lateral (
> select rate
> from exchange
> where target='USD'
> and source=a.currency
> order by date desc
> limit 1) e
> where a.id=19
> for update;

> If I understand the documentation correctly, both rows, the one from
> exchange and the one from account are locked, right?

A look at the plan for this suggests that all rows returned by the
sub-select will end up row-locked (whether or not they actually join
to "a"). Note the LockRows node in the sub-select.

> However, if I create a SQL function like this: [ no locking happens ]

FOR UPDATE locking doesn't propagate into functions. For a moment
I felt like this was a planner bug, but really it isn't: the locking
would certainly not have propagated into a non-inlined function, so
if the planner were to make it happen when inlining, that would make
inlining change the semantics, which it should not.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2015-02-26 15:16:38 Re: "JSON does not support infinite date values"
Previous Message Andrew Dunstan 2015-02-26 14:55:44 Re: "JSON does not support infinite date values"