| 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 |
| 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 |