I think I know what you are concerned about. May be I did not explain my 
solution very clearly.
(i) Using a variable named last_syslogger_file_time replace 
first_syslogger_file_time in syslogger.c. When postmaster initialize logger 
process,   last_syslogger_file_time will be assign the time stamp when logger 
start, then fork the child process for logger. Later logger will create a log 
file based on last_syslogger_file_time . And   last_syslogger_file_time in the 
postmaster process will be inherited by other  auxiliary processes 

(ii) when pgstat process initialize, it will read  last_syslogger_file_time 
from pg stat file of last time (because pgstat process will write it to pg stat 
file). And then pgstat process will get last_syslogger_file_time inherit from 
postmaster,  if this version of  last_syslogger_file_time is larger then that 
read from the stat file, it means logger create a new log file so use it as the 
latest value; else means pgstat process crashed before, so it need to use the 
value from stat file as the latest.
(iii) when logger rotate a log file, it will assign time stamp to 
last_syslogger_file_time  and send it to pg_stat process. And pg_stat process 
will write last_syslogger_file_time to stat file so can be read by other 
backends.
(iiii) Adding a stat function named pg_stat_get_log_file_name, when user call 
it, it will read  last_syslogger_file_time from stat file and construct the log 
file name based on log file name format and last_syslogger_file_time, return 
the log file name eventually.


However, there is a risk for this solution: when logger create a new log file 
and then try to send new last_syslogger_file_time to pg_stat process, and 
pg_stat process crash at this moment, so the new pg_stat process cannot get the 
latest  last_syslogger_file_time. However, I think this case is a corner case. 

------------------
Jerry Yu
https://github.com/scarbrofair


 




------------------ Original ------------------
From:  "Tom Lane";<t...@sss.pgh.pa.us>;
Date:  Thu, Feb 25, 2016 10:47 PM
To:  "Robert Haas"<robertmh...@gmail.com>; 
Cc:  "Euler Taveira"<eu...@timbira.com.br>; "Armor"<yupengst...@qq.com>; 
"Alvaro Herrera"<alvhe...@2ndquadrant.com>; "Pgsql 
Hackers"<pgsql-hackers@postgresql.org>; 
Subject:  Re: [HACKERS] get current log file



Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Feb 25, 2016 at 1:15 AM, Euler Taveira <eu...@timbira.com.br>>> wrote:
>>> 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.

Yes, allowing the syslogger to depend on shared memory is right out.
I don't particularly care for having it assume the stats collector
exists, either -- in fact, given the current initialization order
it's physically impossible for syslogger to send to stats collector
because the former is started before the latter's communication
socket is made.

I haven't actually heard a use-case for exposing the current log file name
anyway.  But if somebody convinced me that there is one, I should think
that the way to implement it is to report the actual *name*, not
components out of which you could reconstruct the name only by assuming
that you know everything about the current syslogger configuration and
the code that builds log file names.  That's obviously full of race
conditions and code-maintenance hazards.

                        regards, tom lane

Reply via email to