Re: v12.0: segfault in reindex CONCURRENTLY
От | Alvaro Herrera |
---|---|
Тема | Re: v12.0: segfault in reindex CONCURRENTLY |
Дата | |
Msg-id | 20191013191834.GA11662@alvherre.pgsql обсуждение исходный текст |
Ответ на | v12.0: segfault in reindex CONCURRENTLY (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: v12.0: segfault in reindex CONCURRENTLY
Re: v12.0: segfault in reindex CONCURRENTLY |
Список | pgsql-hackers |
On 2019-Oct-13, Justin Pryzby wrote: > On Sun, Oct 13, 2019 at 03:10:21PM -0300, Alvaro Herrera wrote: > > On 2019-Oct-13, Justin Pryzby wrote: > > > > > Looks like it's a race condition and dereferencing *holder=NULL. The first > > > crash was probably the same bug, due to report query running during "reindex > > > CONCURRENTLY", and probably finished at nearly the same time as another locker. > > > > Ooh, right, makes sense. There's another spot with the same mistake ... > > this patch should fix it. > > I would maybe chop off the 2nd sentence, since conditionalizing indicates that > we do actually care. > > + * If requested, publish who we're going to wait for. This is not > + * 100% accurate if they're already gone, but we don't care. True. And we can copy the resulting comment to the other spot. (FWIW I expect the crash is possible not just in reindex but also in CREATE INDEX CONCURRENTLY.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: