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

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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