Bruce Momjian wrote:
How is this patch supposed to work? Do people need to modify
postgresql.conf and then sighup the postmaster? It seems more logical
for the super-user to call a server-side function.

I assume calling pg_logfile_rotate() to be the standard way. calling pg_logfile_rotate will increment the internal logfile timestamp, so each backend's next write to the logfile will lead to a reopen. On the other hand, if nothing is to be logged, nothing happens in the backends.

You have
pg_logfile_rotate(), but that doesn't send a sighup to the postmaster so
all the backends will reread the global log file name.

As long as there's no SIGHUP, the logfile name template will not change, so each backend can calculate the logfile's name from the timestamp. In case a SIGHUP *is* issued, the template might have changed, so despite an unchanged timestamp the filename to create might be different. Additionally, SIGHUP will force all backends to check for current logfile name, and close/reopen if their internal timestamp isn't up-to-date with the common timestamp.

Also, what mechanism is there to prevent backends from reading the log filename _while_ it is being modified?

I don't understand your concern. There's no place where the name is stored, only the GUC log_filename which is actually the template, and the timestamp (probably accessed atomically by the processor).

Also there are no documenttion changes.

Hm, seems I missed this in this posting; the previous had it. I'll repost it.

However, looking at the issue of backends all reloading their postgresql.conf files at different times and sending output to different files,

We might have a fraction of a second in practice, when a SIGHUP was issued to reread postgresql.conf, with a log_filename change, and a backend still writing its log to the "old" log because GUC reread is deferred for queries that started before SIGHUP. I don't really see a problem with that.

I wonder if it would be best to create a log process and have
each backend connect to that.  That way, all the logging happens in one

<sigh> All I wanted was displaying the serverlog </sigh>

While this might be ultimately the best solution (we even might find a way to catch stderr without interrupting further stderr piping), currently this doesn't seem to be the right moment. We'd have several inter process issues (and more with win32), which probably need some discussion.
OTOH, if the current implementation is replaced by a log process later, the api interface probably would stay the same.


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to