Re: serverlog rotation/functions

Now that I understand Andreas's patch, and the way he is using shared
memory to store only the timestamp, and how he checks shared memory on
every elog call, I no longer see problems with his method.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I saw Andreas demonstrating the viewing of server log files from pgadmin
> > at Germany Linuxtag, and it certainly was impressive.  However, for
> > heavy, general usage, I don't think this patch is going to work.
>
> That's my gut feeling as well.
>
> > Probably the big thing this program was trying to solve was for the
> > server to know the output file name, even with log file rotation, and I
> > don't see a pipe and 'rotatelogs' process really addressing this.
>
> It could be done.  Given the infrastructure we have now, it's possible
> to imagine the log capture process being a child of the postmaster that
> can respond to GUC SIGHUPs (or forget that and just freeze the file name
> pattern at PGC_POSTMASTER time, which isn't really that big a drawback).
> You'd need the postmaster to create the pipe and then re-point its own
> stdout and stderr at it, but that's doable on Unixen at least (I'm less
> sure about Windows).
>
> If the file names are timestamp-driven in any sane fashion then it's
> easy enough to tell which is newest, so I don't think there is really a
> need for shared memory communication between the log capture program and
> the backends that want to grab some of the data.  Just legislate that
> the naming convention must generate names that sort ASCII-wise into
> time order.
>
> In this scenario the log capture process has robustness requirements
> similar to the postmaster --- you really DO NOT want it to die, ever.
> So the KISS principle applies.  That means keep it away from shared
> memory and try to minimize the number of signals it has to handle.
> (This might be a good reason for treating all its config variables
> as PGC_POSTMASTER; then it does not need to respond to SIGHUP.)
>
> > It was also interesting to do the log rotate as a database call.
>
> That struck me as not only useless but the deliberately hard way to do
> it.  To use that in the real world, you'd have to set up a cron job to
> trigger the rotation, which means a lot of infrastructure and privilege;
> whereas ISTM the point of this feature was to avoid both.  The log
> capture process should just do its own rotation on a pre-configured
> time-interval basis, and/or maximum-file-size basis.  I see zero value
> added in having it respond to external signals.
>
> I would like to have something like this in 7.5, but it's got to be
> designed right.  The patch as structured just feels all wrong to me...
>
>
> > The only idea I have is for the postmaster to close its stderror the
> > create a pipe to roatelogs and someone send all messages into there, and
> > pass the file name from postgresql.conf to that rotatelogs program.
>
> Right, pretty much the same thing I'm thinking.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073