Re: Strange assertion using VACOPT_FREEZE in vacuum.c

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Strange assertion using VACOPT_FREEZE in vacuum.c
Date: 2015-02-18 01:06:48
Message-ID: CAB7nPqQ28G08Us2BtKi=sRQMANxTsKEopuzydEbnEOVKW8Xn=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 18, 2015 at 12:09 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Feb 12, 2015 at 11:54 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> Hi all,
>>
>> When calling vacuum(), there is the following assertion using VACOPT_FREEZE:
>> Assert((vacstmt->options & VACOPT_VACUUM) ||
>> !(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
>> I think that this should be changed with sanity checks based on the
>> parameter values of freeze_* in VacuumStmt as we do not set up
>> VACOPT_FREEZE when VACUUM is used without options in parenthesis, for
>> something like that:
>> Assert((vacstmt->options & VACOPT_VACUUM) ||
>> - !(vacstmt->options & (VACOPT_FULL | VACOPT_FREEZE)));
>> + ((vacstmt->options & VACOPT_FULL) == 0 &&
>> + vacstmt->freeze_min_age < 0 &&
>> + vacstmt->freeze_table_age < 0 &&
>> + vacstmt->multixact_freeze_min_age < 0 &&
>> + vacstmt->multixact_freeze_table_age < 0));
>> This would also have the advantage to limit the use of VACOPT_FREEZE
>> in the query parser.
>> A patch is attached.
>> Thoughts?
>
> I think it's right the way it is. The parser constructs a VacuumStmt
> for either a VACUUM or an ANALYZE command. That statement is checking
> that if you are doing an ANALYZE, you can't specify FULL or FREEZE.
> That makes sense, because there is no ANALYZE FULL or ANALYZE FREEZE
> command.

Yes, the existing assertion is right. My point is that it is strange
that we do not check the values of freeze parameters for an ANALYZE
query, which should be set to -1 all the time. If this is thought as
not worth checking, I'll drop this patch and my concerns.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-02-18 01:21:32 Re: Add min and max execute statement time in pg_stat_statement
Previous Message Alvaro Herrera 2015-02-18 01:00:45 Re: Commit fest 2015-12 enters money time