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

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_*_advice: tsv load failure, etc.
Date: 2026-10-20 18:59:01
Message-ID: d0b79a62-7cf9-4eca-8d08-49c53008a4dd@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Robert,

17.10.2026 00:44, Robert Haas wrote:
> On Wed, Sep 23, 2026 at 1:17 PM Nikolay Samokhvalov<nik(at)postgres(dot)ai> wrote:
>> AI found another case and prepared the attached patch. A single-target
>> PARTITIONWISE entry on a plain table disables every scan path,
>> although the advice only says that the table must not participate in a
>> partitionwise join.
> Here's another set of patches, finally addressing this and your other
> report, plus related problems that I found while digging around in
> this area.

Could you please look at instability in 001_persist.pl found by natural
testing [1]:?
[10:27:25.048](0.445s) # die: error running SQL: 'psql:<stdin>:2: ERROR:  stash modifications are not allowed because
"pg_stash_advice.tsv" has not been loaded yet'
# while running 'psql --no-psqlrc --no-align --tuples-only --quiet --dbname port=29827 host=/tmp/o4DZxN3eiX
dbname='postgres' --file - --variable ON_ERROR_STOP=1' with sql '
#     SELECT pg_create_advice_stash('stash_a');
#     SELECT pg_set_stashed_advice('stash_a', 1001, 'IndexScan(t)');
#     SELECT pg_set_stashed_advice('stash_a', 1002, E'line1\\nline2\\ttab\\\\backslash');
#     SELECT pg_set_stashed_advice('stash_a', 1003, '');
#     SELECT pg_create_advice_stash('stash_b');
#     SELECT pg_set_stashed_advice('stash_b', 2001, 'SeqScan(t)');
# ' at /home/bf/bf-build/culicidae/REL_19_STABLE/pgsql/contrib/pg_stash_advice/t/001_persist.pl line 24.

The failure is pretty clear and can be easily reproduced with this sleep:
--- a/contrib/pg_stash_advice/stashpersist.c
+++ b/contrib/pg_stash_advice/stashpersist.c
@@ -146,2 +146,3 @@ pg_stash_advice_worker_main(Datum main_arg)
         pgsa_read_from_disk();
+pg_usleep(random() % 200000);
         pg_atomic_test_set_flag(&pgsa_state->stashes_ready);

It also makes the test fail other ways:
t/001_persist.pl .. 1/?
#   Failed test 'stashes survived restart'
#   at t/001_persist.pl line 44.
#          got: ''
#     expected: 'stash_a|2
# stash_b|1'
...

#   Failed test 'entry contents survived restart with special characters intact'
#   at t/001_persist.pl line 49.
#          got: ''
#     expected: 'stash_a|1001|IndexScan(t)
# stash_a|1002|line1
# line2 tab\backslash
# stash_b|2001|SeqScan(t)'
...

Probably, the fix can wait as it's the first failure of the test in 6
months.

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2026-10-19%2008%3A24%3A45

Best regards,
Alexander

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-20 19:15:57 Re: query_int wrongly parses zero-padded input
Previous Message Greg Burd 2026-10-20 18:55:54 Re: [PATCH]Fix planner's strictness check for JsonExpr