Andreas Pflug wrote:
> 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.

Oh, I remember now.  You had explained it in a previous email.  Only the
timestamp is saved in global memory (not the name).  Each backend,
before writing, checks the global and reopens if needed.  I see the
LogFileCheckReopen() call in elog.c now, and that is the key to the
whole thing.  Sorry I got confused.

One question, you open the logfile in a+ (append/read).  Isn't "a" alone

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

Sounds good.  I get it now.

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

You are right.  Each backend reads the postgresql.conf file itself so
there is not a real problem except for backends that are delayed
rereading.  I don't see that as a huge problem because if you change the
postgresql.conf to log to a different file location (file name aleady
changes with reload call to be current time), you should expect a delay.
The rotate is pretty fast.

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

OK, I withdraw my concerns.  It looks quite interesting (with docs you
already have).

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to