Re: pg_*_advice: tsv load failure, etc.

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Dongpo Liu <poe(dot)liu(at)pm(dot)me>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_*_advice: tsv load failure, etc.
Date: 2026-10-16 17:05:23
Message-ID: CAN4CZFMoWWdXhrNRk1id=N_K4o5kae3kQTtJi__UfzrEOeUCCA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello

I/Claude noticed one more issue with pg_stash_advice:
if the worker fails to write pg_stash_advice.tsv, the changes it was
trying to save are treated as saved by the next worker.

Any ERROR in pgsa_write_to_disk() makes the worker exit, and the
postmaster restarts it later. stashes_ready is already set, so the new
worker doesn't load the file, and it initializes last_change_count
from the current change_count.

From that point the worker considers everything in memory clean, the
file is only rewritten after some later change or at a clean shutdown.
An immediate shutdown or a crash in between reloads the old file, and
the changes are gone, even though the worker was running for much
longer than persist_interval.

The attached patch starts last_change_count from 0 in a worker that
didn't load the file itself. This writes at the first opportunity
whenever unsaved changes exist. It can cause one redundant rewrite
after a restart, which seems harmless. I also moved the change_count
read in the loading branch before setting stashes_ready, otherwise a
backend change between the two could be counted as loaded.

A TAP test is included for reproduction and as a permanent test case
if we want it.

Attachment Content-Type Size
nocfbot-v1-0001-pg_stash_advice-Don-t-forget-unsaved-changes-afte.patch application/octet-stream 6.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2026-10-16 17:09:53 Re: reltuples kept decreasing with each autovacuum run Re: BUG #18773
Previous Message Álvaro Herrera 2026-10-16 16:40:22 Re: Historic snapshot doesn't track txns committed inBUILDING_SNAPSHOT state