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

From Michael Paquier
Subject Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Date
Msg-id 20200409064426.GQ1606@paquier.xyz
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 09, 2020 at 11:05:50AM +0530, Amit Kapila wrote:
> On Thu, Apr 9, 2020 at 7:07 AM Michael Paquier <michael@paquier.xyz> wrote:
>>  I think that
>> this patch needs tests in sql/vacuum.sql.
>
> We already have one test that is testing an invalid combination of
> PARALLEL and FULL option, not sure of adding more on similar lines is
> a good idea, but we can do that if it makes sense.  What more tests
> you have in mind which make sense here?

As you say, vacuum.sql includes this test:
VACUUM (PARALLEL 2, FULL TRUE) pvactst; -- error, cannot use both PARALLEL and FULL
ERROR:  cannot specify both FULL and PARALLEL options

But based on the discussion of this thread, it seems to me that we had
better stress more option combinations, particularly the two following
ones:
vacuum (full 0, parallel 1) foo;
vacuum (full 1, parallel 0) foo;

Without that, how do you make sure that the compatibility wanted does
not break again in the future?  As of HEAD, the first one passes and
the second one fails.  And as Tushar is telling us we want to
handle both cases in a consistent way.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Next
From: Amit Kapila
Date:
Subject: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error