Le 03/11/2016 à 16:15, Robert Haas a écrit : > On Wed, Oct 26, 2016 at 11:25 PM, Karl O. Pinc <k...@meme.com> wrote: >> What it comes down to is I don't buy the adequacy of the >> ".csv" suffix test and think that "keeping things simple" now >> is a recipe for future breakage, or at least significant future >> complication and confusion when it come to processing logfile >> content. > Sounds like a plausible argument (although I haven't looked at the code).
Yes, the current v11 patch doesn't rely on any extension anymore, instead the log format is now stored with the log file name. >> My thoughts are as follows: Either you know the log format because >> you configured the cluster or you don't. If you don't know the log >> format having the log file is halfway useless. You can do something >> like back it up, but you can't ever look at it's contents (in some >> sense) without knowing what data structure you're looking at. >> >> Therefore pg_current_logfile() without any arguments is, in the sense >> of any sort of automated processing of the logfile content, useless. > Yeah, but it's not useless in general. I've certainly had cases where > somebody gave me access to their PostgreSQL cluster to try to fix a > problem, and I'm struggling to find the log files. Being able to ask > the PostgreSQL cluster "where are all of the files to which you are > logging?" sounds helpful. > +1 Current implementation always returns the log file in use by the logging collector when pg_current_logfile() is called without arguments. If stderr and csvlog are both enabled in log_destination, then it will return the stderr log. If you need to specifically ask for the csvlog file you can give it with as pg_current_logfile parameter. -- Gilles Darold Consultant PostgreSQL http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
