Sam Mason <sam@xxxxxxxxxxxxx> writes: > On Mon, Nov 10, 2008 at 02:30:41PM -0800, Steve Atkins wrote: >> On Nov 10, 2008, at 1:35 PM, Tom Lane wrote: >> >Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> writes: >> >>It seems that there is enough need for this feature, that it has been >> >>implemented multiple times -- but most of them will fail in corner >> >>cases. Seems an obvious candidate for an in-core function ... >> > >> >... which will still fail in corner cases. Not to mention the race >> >condition when the logger has just/is about to switch. >> >> Also, it's going to be a fairly rare app that will need to both >> look at the current logfile and access the database, so providing >> visibility via a sql function seem clunky. > > Indeed, logfiles seem to be in a different world than from inside the > database. It seems there are a couple of options; go and ask PG when > you want to know (pg_ctl seems like a reasonable place IMHO) or have > PG tell you when it's rotating logs, ala the current archiving of WAL > files. > >> Maybe just have the logger maintain a symlink to the current >> logfile, > > If used; a log archival program could do this. > >> or log to a static filename and only use a dynamically >> generated filename when renaming the log file during rotation? > > However, this seems like a simpler solution altogether---no need to even > ask as you know the answer already! > > This does still leave the question of whether there should be a log > archival program around to tell you when they actually rotate. Going > by the fact that people appear to cope with the current behavior, this > just seems unnecessarily complicated and can reasonably be delayed for a > while. If I may revive this thread... While generally sane and lightweight, the symlink approach still leaves the chance for a race condition at the time of the switch. What if we add an option for logging collector to duplicate every write to the current file to a non-blocking fifo or something like that? This seems to solve the problem of running "tail -f" against the current log stream, which was the original request: http://www.postgresql.org/message-id/Pine.GSO.4.64.0811101325260.9276@xxxxxxxxxxx The fifo, however only allows for only one reader connection if I'm not missing something. -- Alex -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general