Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended - Mailing list pgsql-hackers

From David Rowley
Subject Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended
Date
Msg-id CAApHDvqt=BM-JQi1R1ynPbEL8YZuVtcz8aJ6qGeCCHb8siV0Ow@mail.gmail.com
Whole thread Raw
In response to Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: VACUUM (PARALLEL) option processing not using DefElem the way it was intended
List pgsql-hackers
On Thu, 9 Oct 2025 at 05:57, Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> On 2025-Oct-08, Masahiko Sawada wrote:
> > ereport(ERROR,
> >          (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> >           errmsg("BUFFER_USAGE_LIMIT option must be 0 or between %d kB
> > and %d kB",
> >                  MIN_BAS_VAC_RING_SIZE_KB, MAX_BAS_VAC_RING_SIZE_KB),
> >           hintmsg ? errhint("%s", _(hintmsg)) : 0));
> >
> > Should we also change this for consistency with how we handle other
> > VACUUM options?
>
> I would appreciate that, and also a change there from errhint() to
> errhint_internal.

Ok, I've adjusted that in the attached.

David

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Proposal: Allow reads to proceed during FK/trigger drops by reducing relation-level lock from AccessExclusive to ShareRowExclusive
Next
From: Peter Smith
Date:
Subject: Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE