Re: Vacuum o/p with (full 1, parallel 0) option throwing an error - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Date
Msg-id CA+TgmoZ5JBrbzB4nY-537kO-2BNqAeuj_6Ts5EEzKwi=D2p4nw@mail.gmail.com
Whole thread Raw
In response to Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Apr 9, 2020 at 1:36 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier <michael@paquier.xyz> wrote:
> > On Wed, Apr 08, 2020 at 01:38:54PM -0500, Justin Pryzby wrote:
> > > I think the behavior is correct, but the error message could be improved, like:
> > > |ERROR:  cannot specify FULL with PARALLEL jobs
> > > or similar.
> >
> > Perhaps "cannot use FULL and PARALLEL options together"?
> >
>
> We already have a similar message "cannot specify both PARSER and COPY
> options", so I think the current message is fine.

So, whether the error message is OK depends on the details. The
situation as I understand it is that a vacuum cannot be both parallel
and full. If you disallow every command that includes both key words,
then the message seems fine. But suppose you allow

VACUUM (PARALLEL 1, FULL 0) foo;

There's no technical problem here, because the vacuum is not both
parallel and full. But if you allow that case, then there is an error
message problem, perhaps, because your error message says that you
cannot specify both options, but here you did specify both options,
and yet it worked. So really if this case is allowed a more accurate
error message would be something like:

ERROR: VACUUM FULL cannot be performed in parallel

But if you used this latter error message yet disallowed VACUUM
(PARALLEL 1, FULL 0) then it again wouldn't make sense, because the
error message would be now forbidding something that you never tried
to do.

The point is that we need to decide whether we're going to complain
whenever both options are specified in the syntax, or whether we're
going to complain when they're combined in a way that we don't
support. The error message we choose should match whatever decision we
make there.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Report error position in partition bound check
Next
From: Fujii Masao
Date:
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)