Re: Patch to implement pg_current_logfile() function

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Patch to implement pg_current_logfile() function
Дата
Msg-id CA+TgmoYA7xD4zyFK1bycLQH5e80Ly7MpYPG1PGmAzfoX1q0d5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch to implement pg_current_logfile() function  ("Karl O. Pinc" <kop@meme.com>)
Ответы Re: Patch to implement pg_current_logfile() function
Список pgsql-hackers
On Wed, Oct 26, 2016 at 11:25 PM, Karl O. Pinc <kop@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).

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

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Speed up Clog Access by increasing CLOG buffers
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Row level security implementation in Foreign Table in Postgres