Horton
Menu

Re: cleanup patches for incremental backup

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-29T21:13:21Z
Lists: pgsql-hackers 
On Mon, Jan 29, 2024 at 03:18:50PM -0500, Robert Haas wrote:
> I'm wondering if what we need to do is run pg_walsummary on both
> summary files in that case. If we just pick one or the other, how do
> we know which one to pick?

Even if we do that, isn't it possible that none of the summaries will
include the change?  Presently, we get the latest summarized LSN, make a
change, and then wait for the next summary file with a greater LSN than
what we saw before the change.  But AFAICT there's no guarantee that means
the change has been summarized yet, although the chances of that happening
in a test are probably pretty small.

Could we get the LSN before and after making the change and then inspect
all summaries that include that LSN range?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid overflow in MaybeRemoveOldWalSummaries().

  2. Revert "Temporary patch to help debug pg_walsummary test failures."

  3. Revise pg_walsummary's 002_blocks test to avoid spurious failures.

  4. Temporary patch to help debug pg_walsummary test failures.

  5. More documentation updates for incremental backup.

  6. Fix typos.

  7. Fix typo.

  8. Try to fix pg_walsummary buildfarm failures.

  9. Repair various defects in dc212340058b4e7ecfc5a7a81ec50e7a207bf288.

  10. Add new pg_walsummary tool.

  11. Add new function pg_get_wal_summarizer_state().

  12. Document WAL summarization information functions.