Re: LOCK for non-tables - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: LOCK for non-tables
Date
Msg-id 1295036214.23290.97.camel@ebony
Whole thread Raw
In response to Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
> >> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
> >> every application using any form of LOCK at all, which is what I think
> >> your proposal will amount to in practice. 
> 
> > Can I suggest that we don't break anything at all?
> 
> > pg_lock_object(objectname, objecttype, mode);
> > or
> > pg_lock_sequence(name, mode);
> 
> > is all we need...
> 
> No, that will not work at all.  LOCK has to be a utility command.
> A function called by SELECT isn't a substitute, because SELECT
> will acquire a transaction snapshot before executing the function,
> and that breaks many use cases for locks.

But it doesn't break the use case for locking sequences, ISTM.

Anyway, any suggestion that randomly breaks user applications is not
good. If there is a good reason to do that, OK, but I don't see that
here. 

It's a major undertaking trying to write software that runs against
PostgreSQL for more than one release. We should be making that easier,
not harder.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Database file copy
Next
From: Jan Urbański
Date:
Subject: Re: Wildcard search support for pg_trgm