Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Дата
Msg-id CAA4eK1Lsh3cQv0TbqBgOO_r0TQ6CbA9MtJ3VxCDqCjoMi6atPg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Fri, Oct 14, 2022 at 11:51 PM Andres Freund <andres@anarazel.de> wrote:
>
> How about something like:
>
>   XXX: This code is wrong, we're overwriting the buffer before "acquiring" the
>   cleanup lock. Currently this is not known to have bad consequences because
>   XYZ and the fix seems a bit too risky for the backbranches.
>

It looks mostly good to me. I am slightly uncomfortable with the last
part of the sentence: "the fix seems a bit too risky for the
backbranches." because it will stay like that in the back branches
code even after we fix it in HEAD. Instead, can we directly use the
FIXME tag like in the comments: "FIXME: This code is wrong, we're
overwriting the buffer before "acquiring" the cleanup lock. Currently,
this is not known to have bad consequences because no other backend
could find this bucket unless the meta page is updated."? Then, in the
commit message, we can use that sentence, something like: "...  While
fixing this issue, we have observed that cleanup lock is not required
on the new bucket for the split operation as we're overwriting the
buffer before "acquiring" the cleanup lock. Currently, this is not
known to have bad consequences and the fix seems a bit too risky for
the back branches.

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: ExecRTCheckPerms() and many prunable partitions
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Improve description of XLOG_RUNNING_XACTS