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
12 matches
Mail list logo
