Re: SELECT FOR UPDATE differs inside and outside a pl/pgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Shewmaker <mark(at)primefactor(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: SELECT FOR UPDATE differs inside and outside a pl/pgsql
Date: 2003-12-18 15:11:33
Message-ID: 19667.1071760293@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Mark Shewmaker <mark(at)primefactor(dot)com> writes:
> On Wed, 2003-12-17 at 19:57, Tom Lane wrote:
>> Mark Shewmaker <mark(at)primefactor(dot)com> writes:
>>> If a "FOR UPDATE executes before LIMIT" rule stopped the function
>>> from ever locking a row, it's still curious why didn't it stop the
>>> direct command from ever locking a row as well.
>>
>> I think it would. Did you try the test the other way around (with the
>> direct command being blocked behind someone who deletes the first row)?

> Yes, or at least I've done the test that I think you're asking about.

So you have. Your session B_1 (second column) shows exactly the
behavior I expected: the first invocation of SELECT FOR UPDATE
fails to lock any row. You manually did the equivalent of looping
as in myfunction(). So it looks the same to me.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Rich Hall 2003-12-18 15:14:25 Re: plpgsql For SQLQuery Loop Flags Error
Previous Message Paul Punett 2003-12-18 14:56:35 plpgsql Integer Concat To String