Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Date
Msg-id CAA4eK1Lsh3cQv0TbqBgOO_r0TQ6CbA9MtJ3VxCDqCjoMi6atPg@mail.gmail.com
Whole thread Raw
In response to Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions
Next
From: Amit Kapila
Date:
Subject: Re: Improve description of XLOG_RUNNING_XACTS