Re: Explicit relation name in VACUUM VERBOSE log

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit relation name in VACUUM VERBOSE log
Date: 2017-08-23 01:59:40
Message-ID: CAD21AoCV0Xx3ePP6XM=coZQbgBs-Fwfyqu-SADWAOPqWb+c5TA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 15 August 2017 at 02:27, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
>> Is there any reasons why we don't
>> write an explicit name in vacuum verbose logs?
>
> None. Sounds like a good idea.
>
>> If not, can we add
>> schema names to be more clearly?
>
> Yes, we can. I'm not sure why you would do this only for VACUUM
> though? I see many messages in various places that need same treatment

Yeah, I was thinking that too. But since there are a lot of message
that output relation name I proposed this for the first step.

> I would also be inclined to do this by changing only the string
> presented, not the actual message string.

+1

> e.g.
> replace RelationGetRelationName() with
> RelationGetOptionallyQualifiedRelationName()
> and then control whether we include this new behaviour with
> log_qualified_object_names = on | off

Is there any case where we don't want to get non-qualified object
names? If users want to get the same log message as what they got so
far, it would be better to have a GUC that allows us to switch between
the existing behavior and the forcibly logging qualified object names.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-08-23 04:15:35 Re: Proposal: Improve bitmap costing for lossy pages
Previous Message Michael Paquier 2017-08-23 00:52:45 Re: Regression stoping PostgreSQL 9.4.13 if a walsender is running