Re: Concurrent ALTER SEQUENCE RESTART Regression

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jason Petersen <jason(at)citusdata(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Concurrent ALTER SEQUENCE RESTART Regression
Date: 2017-05-03 05:19:16
Message-ID: 448422f6-9b83-3146-3602-6bd40997003e@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 02/05/17 20:40, Robert Haas wrote:
> On Tue, May 2, 2017 at 1:36 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> But by the same token surely we don't want to do
>>> CatalogUpdateIndexes() while holding the buffer lock either; mutual
>>> exclusion needs to be managed at some higher level, using, say, a
>>> heavyweight tuple lock.
>>
>> Right, I don't want that to happen - I think it means we need a proper
>> lock here, but Peter seems to be against that for reasons I don't
>> understand. It's what Michael had suggested in:
>> http://archives.postgresql.org/message-id/CAB7nPqRev_wK4k39hQBpQZRQ17v29guxfobnnmTYT_-hUU67BA%40mail.gmail.com
>
> Yes, I didn't understand Peter's objection, either. It's true that
> there are multiple levels of locks here, but if we've got things
> failing that used to work, then we've not got all the right ones.
>

I do understand the objection, Peter wants to keep metadata
transactional which I would prefer as well (and that's not going to be
the case with Michael's approach). It could be done if ALTER SEQUENCE
held stronger lock on the sequence relation though, but it needs to
block nextval as well in that case (which I think would mean nextval
would need row share lock, unless we are okay with doing access
exclusive lock during ALTER) as I mentioned up thread.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Craig Ringer 2017-05-03 05:20:24 Re: [HACKERS] Re: BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode
Previous Message Haribabu Kommi 2017-05-03 04:32:54 Re: [BUGS] BUG #14634: On Windows pg_basebackup should write tar to stdout in binary mode

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2017-05-03 05:19:22 Re: CTE inlining
Previous Message Petr Jelinek 2017-05-03 04:47:27 Re: logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)