Re: Patch to implement pg_current_logfile() function

From: Christoph Berg <myon(at)debian(dot)org>
To: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
Cc: Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to implement pg_current_logfile() function
Date: 2016-10-27 09:07:43
Message-ID: 20161027090743.4yd5tijbemclj2o6@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Karl O. Pinc 2016-10-27 <20161026222513(dot)74cd3def(at)slate(dot)meme(dot)com>
> Since it now can contain multiple pathnames perhaps the name of the
> file should be "current_logfiles"? Seems more descriptive.

Not sure about that, most often it would contain one logfile only, and
catering for that seems fair to me. (But see the next comment below)

> But what if current_logfile contains only a single line? What
> sort of file format does the logfile have? If you don't know
> you can't process the logfile content.
>
> When there's multiple lines in current_logfile your script might
> be looking for a logfile in a particular format. How is the
> script supposed to know the file format of each logfile listed?

My idea here would be to always write out two lines, the first for
stderr, the second for csvlog, and leave the unused one empty. That's
easy to parse from shell scripts.

> Regards the data structure to use to expose the file format
> I can't vouch that "format path" is most future-proof.
> It's what I came up with on the spur of the moment.
> Something like: "format <format>: path <path>",
> where ":" is the field separator and each data element is
> tagged, would still be parseable by the shell "read" built-in
> so long as the path comes last. I don't really care about
> the exact data structure but I do think the file format
> meta-information should be included.

I guess that depends on how likely we think new log formats would be
added in the future. My guess would be that it's rather unlikely, so
going with simple file format makes sense.

> Why not just: SELECT pg_log_format(); since you only ever need to
> know what log format is returned by pg_current_logfile() when called
> without arguments? Otherwise you already know the log format because
> you asked for something specific.

That function already exists: "show log_destination;"

> Therefore pg_current_logfile() without any arguments is, in the sense
> of any sort of automated processing of the logfile content, useless.

The function without arguments is very useful for interactive use,
which is the primary point of this patch in my opinion.

Christoph

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rushabh Lathia 2016-10-27 09:50:36 Re: Gather Merge
Previous Message Ashutosh Bapat 2016-10-27 09:06:04 Re: Push down more full joins in postgres_fdw