Re: get current log file

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Cc: Armor <yupengstone(at)qq(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: get current log file
Date: 2016-02-25 06:21:51
Message-ID: CA+TgmoZojvuqL+3YTrXjWCHdzd7YOXN62pf0wnqy6KyAD7p8GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira <euler(at)timbira(dot)com(dot)br> wrote:
> On 02-02-2016 10:22, Armor wrote:
>> As we known, the name of current log file depends on the number of
>> seconds (for simple, later I will call it last_syslogger_file_time)
>> since Epoch when create new log file. So, for this feature, the key is
>> how syslogger process pass last_syslogger_file_time to backend processes.
>>
> I didn't like the name. Let's call it syslogger_file_name. It describes
> what the variable is (actual file name that syslogger is writing on).
>
>> To pass last_syslogger_file_time, we have 2 solutions: 1, add a
>> global variable to record last_syslogger_file_time which shared by
>> backends and syslogger, so backends can get last_syslogger_file_time
>> very easily; 2 syslogger process send last_syslogger_file_time to pgstat
>> process when last_syslogger_file_time changes, just as other auxiliary
>> processes send stat message to pgstat process, and pgstat process will
>> write last_syslogger_file_time into stat file so that backend can
>> get last_syslogger_file_time via reading this stat file.
>>
> I prefer (1) because (i) logfile name is not statistics and (ii) stats
> collector could not respond in certain circumstances (and even discard
> some messages).

(1) seems like a bad idea, because IIUC, the syslogger process doesn't
currently touch shared memory. And in fact, shared memory can be
reset after a backend exits abnormally, but the syslogger (alone among
all PostgreSQL processes other than the postmaster) lasts across
multiple such resets.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-02-25 07:06:05 Re: [PATCH v5] GSSAPI encryption support
Previous Message Catalin Iacob 2016-02-25 06:06:06 Re: proposal: PL/Pythonu - function ereport