Re: [HACKERS] Solution to UPDATE...INSERT problem

2003-03-26 Thread Tom Lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Uh, why exactly do you think this is race-free?

> How about:

> INSERT INTO table SELECT 1, 'foo' WHERE NOT EXISTS (SELECT TRUE FROM table
> WHERE pkcol=1 FOR UPDATE);

> It's a lot more straightforward and has a FOR UPDATE.  Can this still cause
> unique constraint failures?

Certainly.  FOR UPDATE locks an existing row; it cannot lock the
condition of non-existence of a row.

regards, tom lane


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] Solution to UPDATE...INSERT problem

2003-03-26 Thread Christopher Kings-Lynne

> Uh, why exactly do you think this is race-free?
>
> It looks fancy, but AFAICS the SELECT will return info that is correct
> as of its starting timestamp; which is not enough to guarantee that the
> INSERT won't conflict with another transaction doing the same thing
> concurrently.

How about:

INSERT INTO table SELECT 1, 'foo' WHERE NOT EXISTS (SELECT TRUE FROM table
WHERE pkcol=1 FOR UPDATE);

It's a lot more straightforward and has a FOR UPDATE.  Can this still cause
unique constraint failures?

Chris


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [HACKERS] Solution to UPDATE...INSERT problem

2003-03-26 Thread Tom Lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> INSERT INTO table SELECT 1, 'foo' EXCEPT SELECT 1, 'foo' FROM table WHERE
> pkcol=1;

> See? So now that INSERT statement will insert the row if it doesn't exist,
> or insert zero rows if it does.  You are then guaranteed that your
> transaction will not fail and rollback, so you can repeat your update, or do
> the insert first and then the update, etc.

Uh, why exactly do you think this is race-free?

It looks fancy, but AFAICS the SELECT will return info that is correct
as of its starting timestamp; which is not enough to guarantee that the
INSERT won't conflict with another transaction doing the same thing
concurrently.

regards, tom lane


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]