Re: LOCK for non-tables

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: LOCK for non-tables
Дата
Msg-id 1295036214.23290.97.camel@ebony
обсуждение исходный текст
Ответ на Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: LOCK for non-tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Database file copy
Следующее
От: Jan Urbański
Дата:
Сообщение: Re: Wildcard search support for pg_trgm