Re: %d in log_line_prefix doesn't work for bg/autovacuum workers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
Date
Msg-id 25151.1400276908@sss.pgh.pa.us
Whole thread Raw
In response to Re: %d in log_line_prefix doesn't work for bg/autovacuum workers  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: %d in log_line_prefix doesn't work for bg/autovacuum workers
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
>> It's imo pretty annoying that neither bgworkers nor autovacuum workers
>> show the proper database in the log. Why don't we just populate a global
>> variable in InitPostgres() once we're sure which database the backend is
>> connected to? We could fill fake MyProcPorts, but that doesn't seem like
>> a good idea to me.

> The attached simple patch implements the former idea.

This is basically reintroducing a variable that used to exist and was
intentionally gotten rid of, on the grounds that it'd fail to track
any renaming of the session's current database (cf commit b256f24264).
I'm not sure how much effort ought to be put into dealing with that corner
case; but let's not reintroduce old bugs just for failure to remember
them.

The existing implementation of log line %d has the same issue of course,
so this is not a very good argument not to change %d.  It *is* a reason
not to blindly change get_database_name(MyDatabaseId) calls, which were
coded that way precisely for this reason.  It might also be a reason
not to blithely expose a global variable like this, which would encourage
making of the same mistake in places that might be more critical than %d.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: 9.4 checksum error in recovery with btree index
Next
From: Andres Freund
Date:
Subject: Re: %d in log_line_prefix doesn't work for bg/autovacuum workers