Re: Explicit relation name in VACUUM VERBOSE log

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Explicit relation name in VACUUM VERBOSE log
Date: 2017-08-23 09:12:11
Message-ID: CANP8+j+06_jm4bGwCtt2EO4rObpWXWb5jDKVafZB8uuLPBu2Qw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23 August 2017 at 08:18, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
> On Wed, Aug 23, 2017 at 10:59 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> On Tue, Aug 22, 2017 at 3:23 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> 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.
>
> I can imagine plenty of cases where providing more information is
> valuable, but not really any where it makes more sense to provide less
> information, so -1 for a GUC to control such behavior. I would imagine
> that people are not going to set it anyway. A RangeVar may not set the
> schema_name, so I would suggest to rely on that to decide if the error
> messages show the schema name or name.

We can put in the GUC if there are objections about backwards
compaibility, so I am OK to leave it out.

> Still we are only talking about
> two messages in the vacuum code paths, which are the ones close to the
> checks where is assigned the OID of the relation with a RangeVar.

The proposal is to change all log messages so we have consistency, not
just VACUUM.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-08-23 09:40:53 Re: PATCH: Batch/pipelining support for libpq
Previous Message Ashutosh Bapat 2017-08-23 09:04:27 Re: [PATCH] Push limit to sort through a subquery