From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Lincoln Yeoh" <lyeoh(at)pop(dot)jaring(dot)my> |
Subject: | Re: [GENERAL] Solution to UPDATE...INSERT problem |
Date: | 2003-03-27 09:28:42 |
Message-ID: | 00b401c2f443$420d76c0$6500a8c0@fhp.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> AFAIK the "except" select won't see other inserts in uncommitted
> transactions. If those transactions are committed you will end up with the
> same problem. You can try it yourself, by manually doing two separate
> transactions in psql.
Yeah, I see that now.
> You either have to lock the whole table, or lock at the application layer.
> Some time back I suggested a "lock on arbitrary string" feature for
> postgresql for this and various other purposes, but that feature probably
> wouldn't scale in terms of management (it requires 100% cooperation
amongst
> all apps/clients involved).
>
> There's no "select * from table where pkey=x for insert;" which would
block
> on uncommitted inserts/updates of pkey=x and other selects for
insert/update.
How about user locks? Isn't there something in contrib/ for that??? I
could do a userlock on the primary key, whether it existed or not?
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | kusum m | 2003-03-27 11:09:50 | requesting for command details |
Previous Message | Csaba Nagy | 2003-03-27 09:19:48 | Re: transaction blocking inserts in postgresql 7.3 |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Brown | 2003-03-27 11:32:02 | Deadlock while doing VACUUM?? |
Previous Message | Lincoln Yeoh | 2003-03-27 09:19:18 | Re: Solution to UPDATE...INSERT problem |