Mark Shewmaker <[EMAIL PROTECTED]> writes:
> On Wed, 2003-12-17 at 19:57, Tom Lane wrote:
>> Mark Shewmaker <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
