On Wed, Nov 19, 2025 at 1:50 PM Jakub Wartak <[email protected]> wrote: > > On Mon, Nov 17, 2025 at 5:51 AM Amul Sul <[email protected]> wrote: > > > > On Thu, Nov 6, 2025 at 2:33 PM Amul Sul <[email protected]> wrote: > > > > > > On Mon, Oct 20, 2025 at 8:05 PM Robert Haas <[email protected]> wrote: > > > > > > > > On Thu, Oct 16, 2025 at 7:49 AM Amul Sul <[email protected]> wrote: > > > > [....] > > > Kindly have a look at the attached version. Thank you ! > > > > > > > Attached is the rebased version against the latest master head > > (e76defbcf09). > > Hi Amul, thanks for working on this. I haven't really looked at the > source code deeply (I trust Robert eyes much more than mine on this > one), just skimmed a little bit: > > 1. As stated earlier, get_tmp_walseg_path() is still vulnerable (it > uses predictable path that could be used by attacker in $TMPDIR) >
Yeah, I haven't done anything regarding this since I am unsure of what should be done and what the risks involved are. I am thinking of taking Robert's opinion on this. > 2. On the usability front: > > a. If you do `pg_waldump --path pg_wal.tar -s 0/31000000` it will dump > a lot of WAL records and then print final: > pg_waldump: error: could not find file "000000010000000000000034" in archive > > However, with `pg_waldump --path pg_wal.tar -s 0/31000000 > --stats=record` (not passing '-e') it will simply bailout without > printing stats and with error: > pg_waldump: error: could not find file "000000010000000000000034" in archive > > IMHO, it could print stats if it was capable of getting at least 1 WAL record. > The similar behavior in the current pg_waldump when using the --path option with a WAL directory and a starting LSN. E.g: $ pg_waldump -s 0/04FE36E0 --path=/tmp/backup/tmp/ --stats=record pg_waldump: first record is after 0/04FE36E0, at 0/04FE3F90, skipping over 2224 bytes pg_waldump: error: could not find file "000000010000000000000009": No such file or directory > 3. The most critical issue for me was the initial lack of error > pass-through from pg_waldump (when used with WALs in tar) to the > pg_verifybackup. Now it works fine, so thanks for this: > Thanks, that was exactly the intention -- to complete pg_verifybackup for tar-formatted backup verification. Regards, Amul
