Samuel Tardieu <[EMAIL PROTECTED]> writes:
>>> Do I have the guarantee that, in any event, rows deleted from
>>> table t by the delete won't reappear in the select result?
>>
>> i do not think you have that guarantee in READ COMMITTED mode
>> because there is a slight possibility another backend sneaked a
>> committed insert in between the delete and select
>> statement.
> Yes. But the possible effect your describe (insertion of new rows
> after the DELETE statement and before the SELECT) matches accurately
> the symptoms we are observing.
Hmm. I think you need to look closer. AFAIR the READ COMMITTED
behavior is only an issue if you give the commands interactively
from the client. Inside a plpgsql function we do not do
SetQuerySnapshot() and therefore the snapshot of other transactions'
effects does not advance. So I think the coding should be safe
... at the moment. (A number of people think the lack of
SetQuerySnapshot inside functions is a bug; so the behavior might
change in future.)
Using SERIALIZABLE mode would probably make your code more future-proof,
but if you are presently seeing failures, there's some other effect
involved here.
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
