Re: Is this a problem in GenericXLogFinish()?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is this a problem in GenericXLogFinish()?
Date: 2023-10-31 12:37:50
Message-ID: CA+TgmoZ3fxKQMw1tUDargbyv2HPpXLNC9YhXsbh37Tp52doWMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 30, 2023 at 11:15 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> My understanding is the same. It is possible that my wording is not
> clear. Let me try to clarify again, Michael asked: "do we need the
> cleanup lock on the write buffer even if there are no tuples, and even
> if primary bucket and the write bucket are the same?" My reading of
> his question was do we need a cleanup lock even if the primary bucket
> and write bucket are the same which means the write bucket will be the
> first page in the chain and we need a cleanup lock on it. I think the
> second condition (no tuples) seems irrelevant here as whether that is
> true or false we need a cleanup lock.

Ah, OK, I see now. I missed the fact that, per what Michael wrote, you
were assuming the primary buffer and the write buffer were the same.
In that case I agree, but the whole formulation seems backwards. I
think the clearer way to say this is: we need a cleanup lock on the
primary bucket page no matter what; and we need to write tuples into
the write buffer if there are any tuples to write but not if there
aren't. If the two buffers are the same then the requirements are
added together.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-10-31 12:41:48 Re: Intermittent failure with t/003_logical_slots.pl test on windows
Previous Message Robert Haas 2023-10-31 12:28:07 Re: Requiring recovery.signal or standby.signal when recovering with a backup_label