Path withdrawn by author.
---
Andreas Pflug wrote:
Updated version.
Only timestamp of fresh logfile in shared mem, with sanity checks.
On SIGHUP, timestamp is checked if rotation was issued, as well as
changed
I wrote:
close(2);
d = dup(p[0]);
Assert(d == 2);
Having re-read the pipe(2) man page, of course that should be
d = dup(p[1]);
since it's the writing end of the pipe you want to plug stderr into.
BTW, if it wasn't clear: I'd do the same pushup for stdout too,
just in
We could make the same adjustments when opening a new log file rather
than pipe, no?
---
Tom Lane wrote:
I wrote:
close(2);
d = dup(p[0]);
Assert(d == 2);
Having re-read the pipe(2) man page, of course
Tom Lane wrote:
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,
Still on my radar...
which means a lot of infrastructure and privilege;
whereas ISTM the point of this feature was to
Bruce Momjian wrote:
Also there are no documenttion changes.
Here are the missing docs, freshly created against cvs.
Regards,
Andreas
Index: func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v
retrieving
Bruce Momjian [EMAIL PROTECTED] writes:
However, looking at the issue of backends all reloading their
postgresql.conf files at different times and sending output to different
files, I wonder if it would be best to create a log process and have
each backend connect to that. That way, all the
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
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
However, looking at the issue of backends all reloading their
postgresql.conf files at different times and sending output to different
files, I wonder if it would be best to create a log process and have
each backend connect to that.
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
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 [EMAIL PROTECTED] 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
Tom Lane wrote:
That was something that bothered me too. I think in the patch as given,
the GUC parameter determining the logfile name would have to be
PGC_POSTMASTER, ie, you could not change it on the fly because the
backends wouldn't all switch together.
In my original posting it was
Bruce Momjian [EMAIL PROTECTED] writes:
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.
The fundamentally unfixable problem with his method is
Updated version.
Only timestamp of fresh logfile in shared mem, with sanity checks.
On SIGHUP, timestamp is checked if rotation was issued, as well as
changed log_filename setting from postgresql.conf.
Regards,
Andreas
Index: src/backend/postmaster/postmaster.c
14 matches
Mail list logo
