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
Andreas wrote:
>
> AFAICS, we have some alternatives:
> - try to grab the currently created files/syslog/eventlog.
> Seems hard to
> do, because we'd depend on additional external tools.
> - redirect stderr to a postgresql.conf known file.
> Disadvantage: breaks
> piping.
> - maintain a shared
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
On Mon, Jun 07, 2004 at 16:06:53 +0200,
Andreas Pflug <[EMAIL PROTECTED]> wrote:
>
> AFAICS, we have some alternatives:
You could also pipe the logs to a program that writes them to a table
in the database. As long as the logging level wasn't set so high that
inserting the log entries was logge
"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
Bruce Momjian wrote:
Andreas Pflug wrote:
I'd like to see the serverlog even if I can't "go and look at the log
file", because I don't have file access to the server.
Understand. Unfortunately, we don't allow such functionality. The only
solution I can think of is to use syslog and
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 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 d
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
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 daemon? If so, how?
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 daemon? If so, how?
And why wouldn't y
For adminstrator's convenience, I'd like to see a function that returns
the serverlog.
Are there any security or other issues that should prevent me from
implementing this?
Regards,
Andreas
---(end of broadcast)---
TIP 6: Have you searched our lis
34 matches
Mail list logo
