| 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: | Whole Thread | Raw Message | 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 |