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