Re: BUG #14941: Vacuum crashes

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: BUG #14941: Vacuum crashes
Дата
Msg-id 32F4B778-292B-41AF-891A-497B8127CD59@amazon.com
обсуждение исходный текст
Ответ на Re: BUG #14941: Vacuum crashes  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: BUG #14941: Vacuum crashes  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: BUG #14941: Vacuum crashes  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On 12/18/17, 3:30 PM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote:
> According to the following old comment, there might be reason why we
> didn't pass the information to vacuum_rel(). But your patch fetches
> the relation
> name even if the "relation" is not provided. I wonder if it can be
> problem in some cases.

Thanks for taking another look.

I've thought through a few edge cases here, but I haven't noticed
anything that I think is a problem.  If an unspecified relation is
renamed prior to get_rel_name(), we'll use the updated name, which
doesn't seem like an issue.  If an unspecified relation is renamed
between get_rel_name() and the log statement, we'll use the old name,
which seems possible in the current logging logic for VACUUM/ANALYZE.
And if an unspecified relation is dropped just prior to
get_rel_name(), the result will be NULL, and the logging will be
skipped (as it already is for concurrently dropped relations that are
not specified in the command).

Nathan


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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: BUG #14941: Vacuum crashes
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Parallel Hash take II