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 lo
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 rev
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
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, o
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
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> 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).
> Given the issues we've had with stdout/stderr on mingw, I'm not
> convinced
> > 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
> possib
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 metho
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 PGC_POSTM
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
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:
> Br
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 stan
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 connec
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 wil
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
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. You have
pg_logfile_rotate(), but that doesn't send a sighup to the postmaster so
all the backends will reread t
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
==
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
The attached patch includes serverlog rotation with minimal shared
memory usage as discussed and functions to access it.
This patch is still unsafe and unworkable. Why would you make the
mechanism dependent on shared memory *and* a
Andreas Pflug <[EMAIL PROTECTED]> writes:
> The attached patch includes serverlog rotation with minimal shared
> memory usage as discussed and functions to access it.
This patch is still unsafe and unworkable. Why would you make the
mechanism dependent on shared memory *and* an intermediate data
The attached patch includes serverlog rotation with minimal shared
memory usage as discussed and functions to access it.
Regards,
Andreas
Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sg
20 matches
Mail list logo
