Re: pg_wal_summary_contents() and pg_walsummary may return different results on the same WAL summary file

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_wal_summary_contents() and pg_walsummary may return different results on the same WAL summary file
Date: 2024-07-03 13:42:33
Message-ID: CA+TgmoYyaBAxLF+nbt+pRQ6CnNzQRwSrR-crPCTRcfN=8Rwy0g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 3, 2024 at 5:34 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> pg_wal_summary_contents() seems to miss the summary information with "limit" that pg_walsummary reports. This appears to be a bug. The attached patch fixes this.

Oops. It looks like pg_wal_summary_contents() forgets to emit the
limit block when that's the only data for a particular relation fork.
And maybe you can make it emit the limit block multiple times if the
list of block numbers is long enough.

Thanks for the patch. I think you can commit and back-patch this, but
I don't think the commit message is quite right, because it's not like
this code just NEVER executes where it is located currently. Or am I
missing something?

> By the way, pg_wal_summary_contents() and pg_walsummary perform nearly the same task but are implemented in different functions. This could be the root of issues like this. In the future, it would be better to have a common function for outputting the WAL summary file that both can use.

It's entirely possible that, with some refactoring, more code could be
shared. I tried to make all of the blkreftable stuff reusable, but I
didn't pay as much attention to synchronizing up the various users of
it. However, the fact that pg_walsummary is frontend code and
pg_wal_summary_contents() is backend code does make it hard to get
perfect reuse. I think if you go through pg_wal_summary_contents(),
you'll find that almost every line of that function contains something
backend-specific.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2024-07-03 13:46:56 Re: Useless parameter 'cur_skey' in IndexScanOK
Previous Message Aleksander Alekseev 2024-07-03 13:41:21 Re: Useless parameter 'cur_skey' in IndexScanOK