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
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" |