Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Дата
Msg-id 2913.1494426542@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
> On 10/05/17 07:09, Peter Eisentraut wrote:
>> I think the correct fix is to have nextval() and ALTER SEQUENCE use
>> sensible lock levels so that they block each other.  Since
>> nextval() currently uses AccessShareLock, the suggestion was for
>> ALTER SEQUENCE to therefore use AccessExclusiveLock.  But I think a
>> better idea would be for nextval() to use RowExclusiveLock
>> (analogous to UPDATE) and ALTER SEQUENCE to use
>> ShareRowExclusiveLock, which would also satisfy issue #1.

> When I proposed this upstream, Andres raised concern about performance
> of nextval() if we do this, did you try to run any benchmark on this?

As long as it doesn't block, the change in lock strength doesn't actually
make any speed difference does it?

If we were taking AccessExclusiveLock somewhere, I'd be worried about
the cost of WAL-logging those; but this proposal does not include any.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] 'nocopy data' option is set in SUBSCRIPTION but stilldata is getting migrated
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: [HACKERS] idea: custom log_line_prefix components besidesapplication_name