Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
От | Petr Jelinek |
---|---|
Тема | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Дата | |
Msg-id | 448422f6-9b83-3146-3602-6bd40997003e@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
|
Список | pgsql-bugs |
On 02/05/17 20:40, Robert Haas wrote: > On Tue, May 2, 2017 at 1:36 PM, Andres Freund <andres@anarazel.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 -- 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 по дате отправления: