Were are we on this?
---
Andreas Pflug wrote:
Tom Lane wrote:
This has got portability issues (fopen(ab))
My doc says b is ignored on ansi systems, and recommends using it. Do
you have other experiences?
and
Bruce Momjian wrote:
I was thinking of close/reopen so log files
could be rotated.
Log file rotation is fine, if we find a consensus quite soon how to
implement it... Seems as if I might find some time to implement it until
feature freeze.
The attached patch has the default filename issue
Andreas Pflug [EMAIL PROTECTED] writes:
The attached patch has the default filename issue fixed, and
documentation. Since I don't have a doc build system functional, there
might be tag mismatches or other typos; please check. IMHO this should
be committed without waiting for log rotation
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
The attached patch has the default filename issue fixed, and
documentation. Since I don't have a doc build system functional, there
might be tag mismatches or other typos; please check. IMHO this should
be committed without
Tom Lane wrote:
This has got portability issues (fopen(ab))
My doc says b is ignored on ansi systems, and recommends using it. Do
you have other experiences?
and I don't care for its
use of malloc in preference to palloc either.
Do we already have an applicable memory context in the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
Me
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
I
Andreas Pflug wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster
Andreas Pflug wrote:
Sorry I didn't get back on this earlier, yesterday morning my internet
access was literally struck by lightning, I'm running temporary hardware
now.
Bruce Momjian wrote:
Looks good to me. The only issue I saw was that the default file name
mentioned in
Bruce Momjian [EMAIL PROTECTED] writes:
Actually, my idea of sending a message to stderr saying we are using a
pre-configured file is so folks aren't surprised by the fact they can't
see any stderr anymore.
Hm? I thought we'd just established that the patch wasn't going to
suppress output to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Actually, my idea of sending a message to stderr saying we are using a
pre-configured file is so folks aren't surprised by the fact they can't
see any stderr anymore.
Hm? I thought we'd just established that the patch wasn't going
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
Is this ready to be added to the patch queue?
---
Andreas Pflug wrote:
Magnus Hagander
Bruce Momjian [EMAIL PROTECTED] writes:
Looks good to me. The only issue I saw was that the default file name
mentioned in postgresql.conf doesn't match the actual default.
I'm really not happy with the concept that the postmaster overrides
its stderr direction.
Magnus Hagander wrote:
Specifically about the logs, I still think there is a lot of value to
being able to read the logs remotely even if you can't restart
postmaster.
Since I believe that retrieving the logs easily without server file
access is a feature that's welcomed by many users, here's my
Andreas Pflug wrote:
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
For adminstrator's convenience, I'd like to see a function that
returns the serverlog.
What do you mean by returns the serverlog? Are you going to magically
recover data that has gone to stderr or the syslogd
Andreas Pflug [EMAIL PROTECTED] writes:
Hm, what I missed is that pg_ctl's -l parameter converts to a simple
stderr redirection, and it's hardly possible to find out where it's going.
This could be solved by a file log_destination option or a
freopen(...,stderr) from a guc variable.
Any
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: 07 June 2004 14:30
To: Andreas Pflug
Cc: PostgreSQL Development
Subject: Re: [HACKERS] serverlog function (log_destination file)
Andreas Pflug [EMAIL PROTECTED] writes:
Hm
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Hm, what I missed is that pg_ctl's -l parameter converts to a simple
stderr redirection, and it's hardly possible to find out where it's going.
This could be solved by a file log_destination option or a
freopen(...,stderr) from a guc
Dave Page [EMAIL PROTECTED] writes:
... what about adding a GUC variable that can be used to specify an
amount of shared memory to use as a fifo area in which a copy of the log
output is stored for return to clients that might want it (accessing it
via internal functions)?
No, that's a
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 07 June 2004 15:32
To: Dave Page
Cc: Andreas Pflug; PostgreSQL Development
Subject: Re: [HACKERS] serverlog function (log_destination file)
If I were trying to solve Andreas' problem, I'd pipe stderr
to some
Dave Page [EMAIL PROTECTED] writes:
Thanks Tom. I wonder if we (the pgAdmin team) finally need to bite the
proverbial bullet and write a helper daemon that can allow access to
logs as well as config files and pg_ctl etc. as an optional extra
component.
Red Hat's RHDB group already did a fair
Tom Lane wrote:
If I were trying to solve Andreas' problem, I'd pipe stderr to some
program that stores recent log output in a file that I know the location
of and can read from the hypothetical log-grabber function. Actually I
don't see that there's any need to involve Postgres itself in this
Andreas Pflug [EMAIL PROTECTED] writes:
What if there's no file access
If you don't have any access to the machine then you are not really a
DBA, you only play one on TV. You can't for example start and stop the
postmaster remotely. So I don't have a lot of sympathy for the notion
that the
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
What if there's no file access
If you don't have any access to the machine then you are not really a
DBA, you only play one on TV.
However you may call me, I can think of many cases where I'd like to
look at the server log, without
If I were trying to solve Andreas' problem, I'd pipe stderr
to some program that stores recent log output in a file that
I know the location of and can read from the hypothetical
log-grabber function. Actually I don't see that there's any
need to involve Postgres itself in this
25 matches
Mail list logo
