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

From Amit Kapila
Subject Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Date
Msg-id CAA4eK1+rJM92fwuGR+FrpX21gcR+84XCMYe8PU=bQ9LQg3WrGQ@mail.gmail.com
Whole thread Raw
In response to Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Apr 9, 2020 at 7:31 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.
>

I would prefer later as I don't find it a good idea to unnecessarily
block some syntax.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Next
From: Masahiko Sawada
Date:
Subject: Re: SyncRepLock acquired exclusively in default configuration