Re: pg_stash_advice: dump file with overlong stash name crashes worker in a restart loop - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_stash_advice: dump file with overlong stash name crashes worker in a restart loop
Date
Msg-id CA+TgmoZFRNQCO5QZ_E2=_LkZrbOiF0q3MRA5qQnTAoAOdM4vJQ@mail.gmail.com
Whole thread
In response to Re: pg_stash_advice: dump file with overlong stash name crashes worker in a restart loop  (Ayush Tiwari <ayushtiwari.slg01@gmail.com>)
List pgsql-hackers
On Fri, May 29, 2026 at 3:43 PM Ayush Tiwari
<ayushtiwari.slg01@gmail.com> wrote:
> 1. Is the PG_RETURN_NULL() on NULL stash name / query ID intentional, or is
>    it a leftover from an earlier shape of the function? It looks a bit like
>    an attempt to emulate STRICT for just the first two arguments, but the
>    effect is that an accidental NULL (say, a scalar subquery that returned
>    no rows) silently does nothing rather than telling the user something
>    went wrong.

It's intentional, and your guess about emulating STRICT functions is
correct. Of course, this function could choose to throw an ERROR in
such cases, and that wouldn't be wrong, but I couldn't think of a
reason to do it that way, so I didn't.

> 2. While there, I noticed the function's header comment says "If the second
>    argument is NULL, we delete any existing advice stash entry", but the
>    code actually keys the delete path off the third argument (advice_string,
>    PG_ARGISNULL(2)). I think the comment is just stale, does that match
>    your understanding?

Yes, I suppose that needs to say "third".

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication