Re: BUG #18031: Segmentation fault after deadlock within VACUUM's parallel worker

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: BUG #18031: Segmentation fault after deadlock within VACUUM's parallel worker
Дата
Msg-id f0f5ab8f-5e3c-edd1-d6ab-d23263759f53@gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18031: Segmentation fault after deadlock within VACUUM's parallel worker  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: BUG #18031: Segmentation fault after deadlock within VACUUM's parallel worker  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-bugs
Hello Sawada-san,

21.07.2023 11:01, Masahiko Sawada wrote:
> ...
> leading to calling RemoveFromWaitQueue() again. I think we should use
> dclist_delete_from_thoroughly() instead. With the attached patch, the
> issue doesn't happen in my environment.

Thank you for the analysis and the patch! It fixes the issue for me too.

> Another thing I noticed is that the Assert(waitLock) in
> RemoveFromWaitQueue() is useless actually, since we access *waitLock
> before that:

Yeah, I also noticed that, and a simple grep-based script with a little
eyeballing discovered one similar Assert usage:

void
llvm_split_symbol_name(const char *name, char **modname, char **funcname)
{
...
         *funcname = rindex(name, '.');
         (*funcname)++;            /* jump over . */

         *modname = pnstrdup(name + strlen("pgextern."),
                             *funcname - name - strlen("pgextern.") - 1);
         Assert(funcname);

May be it's worth to fix it in passing.

Best regards,
Alexander



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: BUG #18027: Logical replication taking forever
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: BUG #18031: Segmentation fault after deadlock within VACUUM's parallel worker