| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Lukas Fittl <lukas(at)fittl(dot)com> |
| Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_plan_advice |
| Date: | 2026-04-07 14:17:12 |
| Message-ID: | CA+TgmobXFPn9HF4KmRB9Sg=uT2+2ss+jQexpQO4pY_mueCqADg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 4, 2026 at 4:12 AM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
> I think we should document the restrictions on advice names here (i.e.
> they must be alphanumeric or contain an underscore, not start with a
> digit, and maximum NAMEDATLEN).
I committed 0001 without this change. Please feel free to propose a
clean-up patch that adds this. I wasn't certain where the best place
to add it was, or what the wording ought to be exactly.
> > +/*
> > + * Remove all stashes and entries from shared memory.
> > + *
> > + * This is intended to be called before reloading from a dump file, so that
> > + * a failed previous attempt doesn't leave stale data behind.
> > + */
> > +void
> > +pgsa_reset_all_stashes(void)
> > +{
>
> I think this might be good to expose on the SQL level as well - in
> case someone accidentally created a lot of stashes it could be tedious
> to remove them all, e.g. if they wanted to clear all the memory after
> an experiment.
From SQL, you can just do select pg_drop_advice_stash(stash_name) from
pg_get_advice_stashes(), which seems good enough to me. If there's a
compelling reason to have more than that, we can think about it, but I
don't particularly see one, and having fewer exposed entrypoints is
better, ceteris paribus. One disadvantage of that approach is that if
it fails due to some concurrency issue, then you might end up with
some stashes dropped and others not, but I don't see this as being
such a frequent operation that it should really cause an issue.
> > diff --git a/contrib/pg_stash_advice/stashpersist.c b/contrib/pg_stash_advice/stashpersist.c
> > new file mode 100644
> > index 00000000000..da96ee0d803
> > --- /dev/null
> > +++ b/contrib/pg_stash_advice/stashpersist.c
> >...
> > + /* Parse the query ID. */
> > + errno = 0;
> > + queryId = strtoll(queryid_str, &endptr, 10);
> > + if (*endptr != '\0' || errno != 0 || queryid_str == endptr)
> > + ereport(ERROR,
> > + (errcode(ERRCODE_DATA_CORRUPTED),
> > + errmsg("syntax error in file \"%s\" line %u: invalid query ID \"%s\"",
> > + PGSA_DUMP_FILE, lineno, queryid_str)));
> > +
>
> It might be worth adding a queryId == 0 check here, since we won't
> check it later, and its helpful to avoid unpredictable behavior just
> in case someone decided to mess with the file manually.
Good point. Added that and committed 0002. I also changed the
write-to-the-persist file path to take only shared locks instead of
exclusive, since the latter seems unnecessary.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-04-07 14:19:20 | Re: Adding REPACK [concurrently] |
| Previous Message | Matheus Alcantara | 2026-04-07 14:14:05 | Re: MERGE PARTITIONS and DEPENDS ON EXTENSION. |