Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
От | Robert Haas |
---|---|
Тема | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Дата | |
Msg-id | CA+TgmoZne41kmc7bT3LH8r4M2hmxzqK33nPXGhXQmfh9ar4ZZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Список | pgsql-bugs |
On Thu, Apr 27, 2017 at 1:52 AM, Andres Freund <andres@anarazel.de> wrote:= > In contrast to <v10, the actual change of the tuple is *not* happening > with the page lock held. But now we do log XLOG_SEQ_LOG, then unlock > the buffer, and then do a CatalogTupleUpdate(). How is that correct? > And if so, why isn't there a honking large comment explaining why it is? I can't actually understand this complaint. I think this code is buggy, but for different reasons than you do. The page lock is held, because read_seq_tuple() acquires it. And then we call heap_open() with the buffer lock held?! I don't think that's a good idea in any way - we shouldn't be doing complex operations that might acquire a buffer lock while we're holding a buffer lock. 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. Another thing that doesn't look so good about AlterSequence is that it uses RangeVarGetRelid() instead of RangeVarGetsRelidExtended() with RangeVarCallbackOwnsRelation or some derivative thereof. That of course means you can obstruct access to a sequence you don't own. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: