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 CAA4eK1J-CQ4_jt85um8WSeCRjkC4aEtB+Ft43_tFHLVS8n_CQA@mail.gmail.com
Whole thread Raw
In response to Re: Vacuum o/p with (full 1, parallel 0) option throwing an error  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
List pgsql-hackers
On Thu, Apr 9, 2020 at 12:09 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> On Thu, Apr 09, 2020 at 12:06:04AM +0530, Mahendra Singh Thalor wrote:
> > On Wed, 8 Apr 2020 at 22:11, Justin Pryzby <pryzby@telsasoft.com> wrote:
> > >
> >
> > Thanks Justin for the patch.
> >
> > Patch looks fine to me and it is fixing the issue. After applying this
> > patch, vacuum will work as:
> >
> > 1) vacuum (parallel 1, full 0);
> > -- vacuuming will be done with 1 parallel worker.
> > 2) vacuum (parallel 0, full 1);
> > -- full vacuuming will be done.
> > 3) vacuum (parallel 1, full 1);
> > -- will give error :ERROR:  cannot specify both FULL and PARALLEL options
> >
> > 3rd example is telling that we can't give both FULL and PARALLEL
> > options but in 1st and 2nd, we are giving both FULL and PARALLEL
> > options and we are not giving any error. I think, irrespective of
> > value of both FULL and PARALLEL options, we should give error in all
> > the above mentioned three cases.
>
> I think the behavior is correct, but the error message could be improved,
>

Yeah, I also think that the behavior is fine.  We can do what Mahendra
is saying but that will unnecessarily block some syntax and we might
need to introduce an extra variable to detect that in code.

> like:
> |ERROR:  cannot specify FULL with PARALLEL jobs
> or similar.
>

I don't see much problem with the current error message as a similar
message is used someplace else also as mentioned in my previous reply.
However, we can change it if we feel the current message is not
conveying the cause of the problem.

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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Fast DSM segments
Next
From: Masahiko Sawada
Date:
Subject: Multiple FPI_FOR_HINT for the same block during killing btree index items