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 experience
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 postmast
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 with
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 rotati
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 fix
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 was
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
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
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 postgresql.conf doesn't match the actual d
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 t
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 agre
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 ei
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.
reg
Oh, it would need doc additions. I can do that when I apply, or you can
resubmit.
---
Andreas Pflug wrote:
> Magnus Hagander wrote:
>
> >Specifically about the logs, I still think there is a lot of value to
> >being able t
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
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 p
> > 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
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, withou
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 l
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 iss
"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
> -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 Andrea
"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
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 va
> -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
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.
An
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
27 matches
Mail list logo
