Re: Concurrent ALTER SEQUENCE RESTART Regression

On 2017-05-03 07:19:16 +0200, Petr Jelinek wrote:
> 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).

Huh? How does increasing the locklevel (from AccessShare to
ShareUpdateExclusive) make it nontransactional?

> 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.

That one is more complicated, because AccessShareLocks on sequences are
held on for performance reasons... Possibly not really required
anymore, due to fast-path locks? Still'd increase the number of
lock/unlock cycles.

- Andres