Horton

Re: Add support for logging the current role

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Itagaki Takahiro <itagaki.takahiro@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-10T11:27:04Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add support for an application_name parameter, which is displayed in

  2. Make CSV column ordering a bit more logical.

  3. Extend the format of CSV logs to include the additional information supplied

  4. Add virtual transaction IDs to CSVLOG output, so that messages coming from

  5. Provide for logfiles in machine readable CSV format. In consequence, rename

On Thu, Feb 10, 2011 at 06:56:15PM +0900, Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 04:10, Stephen Frost <sfrost@snowman.net> wrote:
> >> I agree that it's logically good design, but we could not accept it
> >> as long as it breaks tools in the real world...
> > If it does, I think it's pretty clear that those tools are themselves
> > broken..
> 
> The word "break" was my wrong choice, but your new parameter still
> requires very wide monitors to display SHOW ALL and pg_settings.
> I'd like to solve the issue even though the feature itself is useful.
> One fast and snappy solution might be to set the default value to
> "default", that means the compatible set of columns.
> Other better ideas?

If some tool barfs on a 330-byte GUC value, we might as well have that tool barf
early and often, not just on non-default values.

FWIW, a 330 byte boot_val doesn't seem like a big deal to me.  If it were over
_POSIX2_LINE_MAX (2048), that might be another matter.

> Other questions I raised before might be matters of preference.
> I'd like to here about them form third person.
>  * name: log_csv_fields vs. csvlog_fields

+1 for csvlog_fields.  We have the precedent of syslog_* and that log_* are all
applicable to more than one log destination.

>  * when to assign: PGC_POSTMASTER vs. PGC_SIGHUP

+1 for PGC_SIGHUP.  PGC_POSTMASTER is mostly for things where we have not
implemented code to instigate the change after startup (usually because the
difficulty/value ratio of doing so is too high).  There's no such problem here,
merely the risk that the DBA might not be prepared to deal with a column list
change mid-logfile.  If anything, let's have the documentation mention
pg_rotate_logfile() as potentially useful in conjunction.

nm