Re: [HACKERS] Additional logging for VACUUM and ANALYZE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Fabrízio Mello <fabriziomello(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Additional logging for VACUUM and ANALYZE
Date: 2017-12-01 13:33:42
Message-ID: CA+Tgmoa8eCsJSEQV7Xuqv2Fdf0D8ZmwrWHw80WfKOUEAEN-wyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 30, 2017 at 10:04 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Nov 8, 2017 at 12:54 AM, Fabrízio de Royes Mello
> <fabriziomello(at)gmail(dot)com> wrote:
>> Great. Changed status to ready for commiter.
>
> The patch still applies, but no committer seem to be interested in the
> topic, so moved to next CF.

The general idea of this patch seems OK to me.

+ rel_lock = true;

I think it would look nicer to initialize this when you declare the
variable, instead of having a separate line of code for that purpose.

+ if (IsAutoVacuumWorkerProcess() && params->log_min_duration >= 0)
+ elevel = LOG;
+ else if (!IsAutoVacuumWorkerProcess())
+ elevel = WARNING;
+ else
+ return;

This can be rewritten with only one call to
IsAutoVacuumWorkerProcess() by reversing the order of the branches.

+ PopActiveSnapshot();
+ CommitTransactionCommand();
+ return false;

vacuum_rel already has too many copies of this logic -- can we try to
avoid duplicating it into two more places? It seems like you could
easily do that like this:

int elevel = 0;
if (relation != NULL)
{
/* maybe set elevel */
}
if (elevel != 0)
{
if (!rel_lock)
/* emit message */
else
/* emit other message */
}

This wouldn't be the first bit of code to assume that elevel == 0 can
be used as a sentinel value meaning "none", so I think it's OK to do
that.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2017-12-01 14:10:23 Re: [HACKERS] Custom compression methods
Previous Message Fabien COELHO 2017-12-01 12:57:40 Re: [HACKERS] pgbench more operators & functions