Re: Parallel vacuum workers prevent the oldest xmin from advancing

Поиск
Список
Период
Сортировка
От Masahiko Sawada
Тема Re: Parallel vacuum workers prevent the oldest xmin from advancing
Дата
Msg-id CAD21AoDMCQBY_0EobM8WbH5ZzVskz6HjAQpxQ4dTWtH+aiHjNw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parallel vacuum workers prevent the oldest xmin from advancing  (Greg Nancarrow <gregn4422@gmail.com>)
Список pgsql-hackers
On Mon, Oct 11, 2021 at 3:01 PM Greg Nancarrow <gregn4422@gmail.com> wrote:
>
> On Wed, Oct 6, 2021 at 6:11 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > To fix it, I thought that we change the create index code and the
> > vacuum code so that the individual parallel worker sets its status
> > flags according to the leader’s one. But ISTM it’d be better to copy
> > the leader’s status flags to workers in ParallelWorkerMain(). I've
> > attached a patch for HEAD.
> >
>
> +1 The fix looks reasonable to me too.
> Is it possible for the patch to add test cases for the two identified
> problem scenarios? (PROC_IN_VACUUM, PROC_IN_SAFE_IC)

Not sure we can add stable tests for this. There is no way in the test
infra to control parallel workers to suspend and resume etc. and the
oldest xmin can vary depending on the situation. Probably we can add
an assertion to ensure a parallel worker for vacuum or create index
has PROC_IN_VACUUM or PROC_IN_SAFE_IC, respectively.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: BUG #17212: pg_amcheck fails on checking temporary relations