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 correct? > > 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 | http://candle.pha.pa.us [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