| From: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: pg_*_advice: tsv load failure, etc. |
| Date: | 2026-10-29 23:26:57 |
| Message-ID: | CAM527d8PqdbDy=PuTLYBJM8-FvvFDr2BLcyFyZhw6Oi9rXb14g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 29, 2026 at 9:59 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I'm guessing that this is fixed by Zsolt's patch, which I just committed.
The 001_persist.pl race Alexander reported still reproduces after
6f16120176 on REL_19_STABLE (61553eacad on master).
Adding pg_usleep(1000000); immediately after pgsa_read_from_disk()
in pg_stash_advice_worker_main(), before stashes_ready is set, makes
the unchanged test on REL_19_STABLE fail at
pg_create_advice_stash('stash_a'):
ERROR: stash modifications are not allowed because
"pg_stash_advice.tsv" has not been loaded yet
The "loaded" log line used by the test after restart also comes before
stashes_ready is set. Once the first race is avoided, the delayed test
fails again when creating stash_c after the first restart.
The attached test-only patch waits for stash creation to succeed at
startup, for the expected stashes to appear after each restart, and for
stash modifications to be allowed after the final empty restart. The
focused TAP test passes with and without the delay on both branches.
The sleep is only for reproduction; it is not in the patch. AI prepared
the patch; I have not manually reviewed it.
Nik
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-pg_stash_advice-Wait-for-worker-readiness-in-persist.patch | application/x-patch | 3.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Michael Paquier | 2026-10-29 23:08:12 | Re: Return pg_control from pg_backup_stop(). |