Re: Concurrent ALTER SEQUENCE RESTART Regression

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: 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-04-26 16:15:53
Message-ID: 9240bf94-44a8-671a-27bd-500eb868226a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 4/25/17 21:24, Michael Paquier wrote:
> Yes, and that's fine, taking a stronger lock on pg_sequence would be
> disruptive for other sessions, including the ones updating pg_sequence
> for different sequences. The point I am trying to make here is that
> the code path updating pg_sequence should make sure that the
> underlying object is properly locked first, so as the update is
> concurrent-safe because this uses simple_heap_update that assumes that
> the operation will be concurrent-safe. For example, take tablecmds.c,
> we make sure that any relation ALTER TABLE works on gets a proper lock
> with relation_open first, in what sequences would be different now
> that they have their own catalog?

Pretty much everything other than tables is a counterexample.

git grep RowExclusiveLock src/backend/commands/*.c

Only tables have an underlying object to lock. Most other DDL commands
don't have anything else to lock and run DDL under RowExclusiveLock.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Martin 2017-04-26 16:18:56 Re: AfterTriggerSaveEvent() Error on altered foreign key cascaded delete
Previous Message Nikolay Samokhvalov 2017-04-26 16:14:17 Re: ON CONFLICT with constraint name doesn't work

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-04-26 16:19:01 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Robert Haas 2017-04-26 16:15:03 Re: Dropping a partitioned table takes too long