Re: sequence locking
От | Andres Freund |
---|---|
Тема | Re: sequence locking |
Дата | |
Msg-id | 201109211940.58306.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: sequence locking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: sequence locking
|
Список | pgsql-hackers |
On Wednesday 21 Sep 2011 19:24:55 Tom Lane wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > > Andres Freund <andres@anarazel.de> wrote: > >> - Its impossible to emulate proper locking yourself because > >> locking is not allowed for sequences > >> > >> Any arguments against allowing it again? It seems to have been > >> allowed in prehistoric times. > > If you think that it used to be allowed, it'd be a good idea to see > if you can find the archived discussions about changing it. The message I was thinking about was http://archives.postgresql.org/pgsql-hackers/2001-10/msg00930.php > > It would be nice to allow it. I've had to create a dummy table just > > to use for locking a sequence (by convention). > One question is what you think the lock means. I believe for example > that taking a non-exclusive regular table lock on a sequence would not > prevent other sessions from doing nextval(); even an exclusive one would > not prevent them from doing so if they had pre-cached values. I don't see what a non-exclusive lock on a sequence should sensibly do so I don't see a problem with not supporting them. That already cached values are not affected by the lock seems to be pretty logical to me - and not really problematic. At least in my cases I would look at last_value from the sequence after locking it- which includes the cached values so its fine that they can be used. The case that somebody already acquired a sequence value that not visible to other sessions has to be taken into account anyway. Greetings, Andres
В списке pgsql-hackers по дате отправления: