Re: remove spurious CREATE INDEX CONCURRENTLY wait

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: remove spurious CREATE INDEX CONCURRENTLY wait
Дата
Msg-id 20200820060929.GB3730@paquier.xyz
обсуждение исходный текст
Ответ на Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: remove spurious CREATE INDEX CONCURRENTLY wait  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список pgsql-hackers
On Wed, Aug 19, 2020 at 02:16:46PM -0400, Alvaro Herrera wrote:
> I did not set the flag in REINDEX CONCURRENTLY, but as I understand it
> can be done too, since in essence it's the same thing as a CIC from a
> snapshot management point of view.

Yes, I see no problems for REINDEX CONCURRENTLY as well as long as
there are no predicates and expressions involved.  The transactions
that should be patched are all started in ReindexRelationConcurrently.
The transaction of index_concurrently_swap() cannot set up that
though.  Only thing to be careful is to make sure that safe_flag is
correct depending on the list of indexes worked on.

> Also, per [1], ISTM this flag could be used to tell lazy VACUUM to
> ignore the Xmin of this process too, which the previous formulation
> (where all CICs were so marked) could not.  This patch doesn't do that
> yet, but it seems the natural next step to take.
>
> [1] https://postgr.es/m/20191101203310.GA12239@alvherre.pgsql

Could we consider renaming vacuumFlags?  With more flags associated to
a PGPROC entry that are not related to vacuum, the current naming
makes things confusing.  Something like statusFlags could fit better
in the picture?
--
Michael

Вложения

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."