Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
От | Andres Freund |
---|---|
Тема | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Дата | |
Msg-id | 20170427011258.2tpv55b6leqe2uva@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression
Re: [BUGS] Concurrent ALTER SEQUENCE RESTART Regression |
Список | pgsql-bugs |
On 2017-04-26 21:07:20 -0400, Peter Eisentraut wrote: > On 4/26/17 19:12, Michael Paquier wrote: > > Well, there are more DDL commands where it is possible to see "tuple > > concurrently updated" easily, an example is ALTER ROLE. So nothing is > > concurrent-proof with this code and I think needs a careful lookup > > because this error should never be something that is user-visible. > > Yeah, it's been like this since time immemorial, so I don't think we > need a last minute fix now. Uh. Until v10 this worked in a somewhat weird way, but it worked. > One thing we could do, since all catalog updates now go through > CatalogTupleUpdate(), is not use simple_heap_update() there but do the > heap_update() directly and provide a better user-facing error message. I think it's unacceptable to regress with an error message here. I've seen sequence DDL being used while concurrent DML was onging in a number of production use cases, and just starting to error out instead of properly blocking doesn't seem acceptable to me. - Andres -- 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 по дате отправления: