Re: Patch to implement pg_current_logfile() function - Mailing list pgsql-hackers

From Karl O. Pinc
Subject Re: Patch to implement pg_current_logfile() function
Date
Msg-id 20161027071422.475e26f5@slate.meme.com
Whole thread Raw
In response to Re: Patch to implement pg_current_logfile() function  (Christoph Berg <myon@debian.org>)
Responses Re: Patch to implement pg_current_logfile() function  (Gilles Darold <gilles.darold@dalibo.com>)
List pgsql-hackers
On Thu, 27 Oct 2016 11:07:43 +0200
Christoph Berg <myon@debian.org> wrote:

> Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3def@slate.meme.com>

> > 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.

That'd work.

> 
> > 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.

Agreed.  I can't see adding any more meta-information other than
file format.

I'm partial to "format <space> path" over just line number, because
it's more explicit.  Either way works.

> > Why not just: SELECT pg_log_format();

> That function already exists: "show log_destination;"

Great, done!  :)

> > 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.

Your comment makes me wonder if pg_current_logfile(), without
arguments, should instead be "SHOW current_logfile;".

I think not, but have no rationale.  Could this be a good idea?

Regards,

Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."                -- Robert A. Heinlein



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Push down more full joins in postgres_fdw
Next
From: Dilip Kumar
Date:
Subject: Re: Speed up Clog Access by increasing CLOG buffers