Re: Simplify VM counters in vacuum code - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Simplify VM counters in vacuum code
Date
Msg-id CAD21AoCGLcbrzNysZuRi7+383fUPP_o0iBNXjXhuf_teK1Ji=g@mail.gmail.com
Whole thread Raw
In response to Re: Simplify VM counters in vacuum code  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Simplify VM counters in vacuum code
List pgsql-hackers
On Thu, Jun 26, 2025 at 10:01 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Wed, Jun 25, 2025 at 2:59 AM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
> >
> > I liked this version more. I agree that the asserts were causing some confusion.
>
> Thanks for the review!
>
> Sawada-san, do you have any objection to this being merged in
> master/18? I know you had said changing the if statements to asserts
> did not feel like a bug fix. However, now that the asserts have been
> removed, do you still feel this way?
>
> I feel simplifying the counters is a clarity improvement and would
> prefer we have it before branching, but I would hold off if you still
> felt this way even with the asserts removed.
>
> (I had originally misunderstood and didn't realize that the page bit
> must be set if the VM bit is set, so that is why I had a guard in the
> empty page case. And for lazy_vacuum_heap_page(), I was being overly
> cautious at the expense of clarity.)

Thank you for updating the patch! The changes in v3 appear
straightforward; the patch eliminates unnecessary codes that were
introduced in the original commit due to some misunderstandings. And I
agreed with your answer[1] to my question. So it looks okay to me to
push it to master/18.

Regards,

[1] https://www.postgresql.org/message-id/CAAKRu_ZFGLXCWkLZv2BT4SLbu%3D3zHPkfx5EeR%2BRupe%3DxCxLaPA%40mail.gmail.com

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Timur Magomedov
Date:
Subject: Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
Next
From: Alexander Korotkov
Date:
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly