Re: cleaning up a few CLOG-related things

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: cleaning up a few CLOG-related things
Date: 2021-01-27 17:35:30
Message-ID: CA+TgmoZJcLbJTdD3X-oNMrU5BxqRvLch4yYCbS-G2dUsxh0peA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 25, 2021 at 2:11 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > [patches 0001 - 0003]
>
> Makes sense.

Great. I committed the first one and will proceed with those as well.

> > So, the CLOG page gets created when nextXid advances from the first
> > value on the page to the second value on the page, not when it
> > advances from the last value on the previous page to the first value
> > on the current page.
> Yes. It took me a moment to understand that explanation, though. I'd
> phrase it something like "nextXid is the next XID that will be used, but
> we want to set latest_page_number according to the last XID that's
> already been used. So retreat by one."

OK, updated the patch to use that language for the comment.

> Having a separate FullTransactionIdToLatestPageNumber() function for
> this seems like overkill to me.

I initially thought so too, but it turned out to be pretty useful for
writing debugging cross-checks and things, so I'm inclined to keep it
even though I'm not at present proposing to commit any such debugging
cross-checks. For example I tried making the main redo loop check
whether XactCtl->shared->latest_page_number ==
FullTransactionIdToLatestPageNumber(nextXid) which turned out to be
super-helpful in understanding things.

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

Attachment Content-Type Size
v2-0001-In-clog_redo-don-t-set-XactCtl-shared-latest_page.patch application/octet-stream 2.0 KB
v2-0002-In-TrimCLOG-don-t-reset-XactCtl-shared-latest_pag.patch application/octet-stream 1.7 KB
v2-0003-In-StartupCLOG-correct-an-off-by-one-error.patch application/octet-stream 2.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2021-01-27 18:47:17 Re: Support for NSS as a libpq TLS backend
Previous Message Andres Freund 2021-01-27 17:09:58 Re: Printing backtrace of postgres processes