Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log
Date
Msg-id CAD21AoCV0Xx3ePP6XM=coZQbgBs-Fwfyqu-SADWAOPqWb+c5TA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 15 August 2017 at 02:27, Masahiko Sawada <sawada.mshk@gmail.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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Regression stoping PostgreSQL 9.4.13 if a walsender is running
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages