Re: Function for listing pg_wal/summaries directory

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: btogiwarayuushi <btogiwarayuushi(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Function for listing pg_wal/summaries directory
Date: 2024-10-07 01:07:10
Message-ID: ZwM0Pt3VGAiK2bDC@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 04, 2024 at 10:02:11AM -0500, Nathan Bossart wrote:
> Could you explain why you feel the existing support functions are
> insufficient?

Because it is not possible to outsource the scan of pg_wal/summaries/
to a different role, no?

On HEAD, one would require a full access to the data folder, as
pg_ls_waldir() does not recurse. Perhaps, rather than introducing a
new function, we should just extend pg_ls_dir_files() so as it can
optionally recurse, then use this option in the existing
pg_ls_waldir() to show stats for pg_wal/ and pg_wal/summary/? You'd
optinally need to print the relative path of the file in the output of
the function, meaning that any summary file in should be shown as
summaries/blah.summary. Just an idea for the bucket of ideas.

This would be unconsistent with the existing
pg_ls_archive_statusdir(), though, so using a new function may be just
better and simpler.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-10-07 01:10:09 Re: System username in pg_stat_activity
Previous Message Michael Paquier 2024-10-07 00:41:36 Re: Add parallel columns for seq scan and index scan on pg_stat_all_tables and _indexes