On Tue, Jan 27, 2026 at 10:02 PM Euler Taveira <[email protected]> wrote: > + * archive_waldump.c > + * A generic facility for reading WAL data from tar archives via archive > + * streamer. > > The other tools (pg_basebackup and pg_verifybackup) that also use astreamer > API > named this similar file as astreamer_SOMETHING.c. It seems a good idea to > follow the same pattern, no? Maybe astreamer_tar_archive.c or > astreamer_archive.c.
There shouldn't be anything specific to tar files in here, and astreamer_archive would be meaningless, since the "a" in "astreamer" stands for archive. What this file is is an archive streamer specific to pg_waldump, hence the name. > Can it enforce a specific order? tar follows an arbitrary order in which the > files is returned by the filesystem. You've been debating a solution to buffer > the WAL contents using memory or spilled files. If it always create the tar in > an alphabetical order, you can reduce the scope of this patch. (Didn't look > what challenges are expected to use a sorted list to generate the tar file.) It's posible to create a tar file in a specific order by specifying command-line arguments to tar in the order you want the tar file to be built. But I think the real thing here is that this limitation is lifted by the following patch. Whether it's worth splitting it apart into two patches this way is debatable. As I have pointed out in my previous reviews, the split hasn't been done very cleanly. -- Robert Haas EDB: http://www.enterprisedb.com
