Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 I don't care for its
use of malloc in preference to palloc either.
Do we already have an applicable memory context in the postmaster at
that early stage of initialization?
Also, pg_logfile() will dump core if LogFileName returns null.
How that?
char *filename=LogFileName();
if (filename)
{
...
free(filename);
}
The bigger issue though is whether this is useful at all, if you cannot
solve the file rotation issue (and I don't think you can). As
implemented, the secondary log file cannot be truncated without
restarting the postmaster. I think that reduces it from a possibly
useful feature to a useless toy.
This patch isn't trying to be better on logfile handling than the
default stderr redirection behavior, besides being able to access it
through the postmaster. Seems you insist to name this a toy, many users
don't.
(The fact that pg_logfile_length
returns int and not something wider is pretty silly in this connection.)
2GB logfile seems pretty big...
Regards,
Andreas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 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 stuff. Regards, Andreas Index: doc/src/sgml/func.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v retrieving revision 1.206 diff -u -r1.206 func.sgml --- doc/src/sgml/func.sgml 2 Jun 2004 21:34:49 - 1.206 +++ doc/src/sgml/func.sgml 11 Jun 2004 17:58:35 - @@ -7308,6 +7308,53 @@ columns do not have OIDs of their own. /para + indexterm zone=functions-misc + primarypg_logfile/primary + /indexterm + indexterm zone=functions-misc + primarypg_logfile_length/primary + /indexterm + para +The functions shown in xref linkend=functions-misc-logfile + deal with the server log file if configured with log_destination + quotefile/quote. +previously stored with the commandCOMMENT/command command. A +null value is returned if no comment could be found matching the +specified parameters. + /para + + table id=functions-misc-logfile +titleServer Logfile Functions/title +tgroup cols=3 + thead + rowentryName/entry entryReturn Type/entry entryDescription/entry/row + /thead + + tbody + row + entryliteralfunctionpg_logfile/function(parametersize_int4/parameter, parameteroffset_int4/parameter)/literal/entry + entrytypecstring/type/entry + entryget a part of the server log file/entry + /row + row + entryliteralfunctionpg_logfile_length/function()/literal/entry + entrytypeint4/type/entry + entryreturn the current length of the server log file/entry + /row + /tbody +/tgroup +/table +para +The functionpg_logfile/function function will return the + contents of the server log file, limited by the size + parameter. If size is NULL, a server internal limit (currently + 5) is applied. The position parameter determines the + starting position of the server log chunk to be returned. A + positive number or 0 will be counted from the start of the file, + a negative number from the end; if NULL, -size is assumed + (i.e. the tail of the log file). +/para + /sect1 sect1 id=functions-array Index: doc/src/sgml/runtime.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.266 diff -u -r1.266 runtime.sgml --- doc/src/sgml/runtime.sgml 10 Jun 2004 22:26:17 - 1.266 +++ doc/src/sgml/runtime.sgml 11 Jun 2004 17:58:46 - @@ -1721,14 +1721,25 @@ listitem para productnamePostgreSQL/productname supports several methods -for loggning, including systemitemstderr/systemitem and -systemitemsyslog/systemitem. On Windows, -systemitemeventlog/systemitem is also supported. Set this +for logging, including systemitemstderr/systemitem, +systemitemfile/systemitem and systemitemsyslog/systemitem. + On Windows, systemitemeventlog/systemitem is also supported. Set this option to a list of desired log destinations separated by a comma. The default is to log to systemitemstderr/systemitem only. This option must be set at server start. /para /listitem + /varlistentry + + varlistentry id=guc-syslog-facility xreflabel=log_filename + termvarnamelog_filename/varname (typestring/type)/term + listitem +para + This option sets the target filename for the log destination + quotefile/quote option. It may be specified as absolute + path or relative to the applicationcluster directory/application. +/para + /listitem /varlistentry varlistentry id=guc-syslog-facility xreflabel=syslog_facility Index: src/backend/postmaster/postmaster.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v retrieving revision 1.403 diff -u -r1.403 postmaster.c --- src/backend/postmaster/postmaster.c 11 Jun 2004 03:54:43 - 1.403 +++ src/backend/postmaster/postmaster.c 11 Jun 2004 17:58:52 - @@ -532,6 +532,9 @@ /* If timezone is not set, determine what the OS uses */ pg_timezone_initialize(); +/* open alternate logfile, if any */ + LogFileOpen(); + #ifdef EXEC_BACKEND write_nondefault_variables(PGC_POSTMASTER); #endif Index:
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 stuff. This has got portability issues (fopen(ab)) and I don't care for its use of malloc in preference to palloc either. Also, pg_logfile() will dump core if LogFileName returns null. The bigger issue though is whether this is useful at all, if you cannot solve the file rotation issue (and I don't think you can). As implemented, the secondary log file cannot be truncated without restarting the postmaster. I think that reduces it from a possibly useful feature to a useless toy. (The fact that pg_logfile_length returns int and not something wider is pretty silly in this connection.) My vote is not to apply until and unless something that can rotate the logfile is demonstrated ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 waiting for log rotation stuff. This has got portability issues (fopen(ab)) and I don't care for its use of malloc in preference to palloc either. Also, pg_logfile() will dump core if LogFileName returns null. The bigger issue though is whether this is useful at all, if you cannot solve the file rotation issue (and I don't think you can). As implemented, the secondary log file cannot be truncated without restarting the postmaster. I think that reduces it from a possibly useful feature to a useless toy. (The fact that pg_logfile_length returns int and not something wider is pretty silly in this connection.) My vote is not to apply until and unless something that can rotate the logfile is demonstrated ... Agreed. Lets see where it goes. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 postmaster at
that early stage of initialization?
Also, pg_logfile() will dump core if LogFileName returns null.
How that?
char *filename=LogFileName();
if (filename)
{
...
free(filename);
}
The bigger issue though is whether this is useful at all, if you cannot
solve the file rotation issue (and I don't think you can). As
implemented, the secondary log file cannot be truncated without
restarting the postmaster. I think that reduces it from a possibly
useful feature to a useless toy.
This patch isn't trying to be better on logfile handling than the
default stderr redirection behavior, besides being able to access it
through the postmaster. Seems you insist to name this a toy, many users
don't.
(The fact that pg_logfile_length
returns int and not something wider is pretty silly in this connection.)
2GB logfile seems pretty big...
Regards,
Andreas
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 either without more thought. If we start logging to a file explicitly, do we need to revisit the log rotation discussion which seems to have gone nowhere several times recently? cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 agree, that's why I implemented it as *additional* log_destination. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 overrides its stderr direction. I agree, that's why I implemented it as *additional* log_destination. One idea would be to send a message to stderr when this option is used stating that everything is going to 'filename'. Also can we close/reopen the file on SIGHUP. My guess is we can't because of all the backends accessing the output file. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 postgresql.conf doesn't match the actual default. I'll fix the default filename difference, postgresql.log seems best. I'll add doc too. One idea would be to send a message to stderr when this option is used stating that everything is going to 'filename'. I can ereport LogFileOpen and LogFileClose, do we need this? Currently, only open problems will be reported. 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. But doesn't syslog have the same issue. Maybe not, and that's why we need a message like: All standard output and standard error are going to postgresql.conf and send that to the processes standard error. Also can we close/reopen the file on SIGHUP. My guess is we can't because of all the backends accessing the output file. I'd also like it flushed in pg_logfile and pg_logfile_length, same problem; any hints welcome. I don't understand this. I was thinking of close/reopen so log files could be rotated. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 stderr. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 to suppress output to stderr. Oh, I didn't see that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 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 proposal.
The attached diff will
- add a guc-variable log_filename
- extend log_destination to accept the keyword 'file'
- elog to that file if configured
- provide two functions pg_logfile_length() and pg_logfile to obtain the
contents.
int4 pg_logfile_length()
cstring pg_logfile(int4 size, int4 position)
size (may be null meaning max) is the chunk size (max: currently 5)
position (may be null meaning -size) is the start position; positive
counting from log file start, negative from end.
Regards,
Andreas
Index: backend/postmaster/postmaster.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/postmaster.c,v
retrieving revision 1.402
diff -u -r1.402 postmaster.c
--- backend/postmaster/postmaster.c 3 Jun 2004 02:08:03 - 1.402
+++ backend/postmaster/postmaster.c 8 Jun 2004 18:07:30 -
@@ -532,6 +532,9 @@
/* If timezone is not set, determine what the OS uses */
pg_timezone_initialize();
+/* open alternate logfile, if any */
+ LogFileOpen();
+
#ifdef EXEC_BACKEND
write_nondefault_variables(PGC_POSTMASTER);
#endif
Index: backend/storage/ipc/ipc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/ipc/ipc.c,v
retrieving revision 1.87
diff -u -r1.87 ipc.c
--- backend/storage/ipc/ipc.c 12 Dec 2003 18:45:09 - 1.87
+++ backend/storage/ipc/ipc.c 8 Jun 2004 18:07:31 -
@@ -111,6 +111,8 @@
on_proc_exit_list[on_proc_exit_index].arg);
elog(DEBUG3, exit(%d), code);
+
+ LogFileClose();
exit(code);
}
Index: backend/utils/adt/misc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/adt/misc.c,v
retrieving revision 1.34
diff -u -r1.34 misc.c
--- backend/utils/adt/misc.c 2 Jun 2004 21:29:29 - 1.34
+++ backend/utils/adt/misc.c 8 Jun 2004 18:07:36 -
@@ -103,3 +103,64 @@
{
PG_RETURN_INT32(pg_signal_backend(PG_GETARG_INT32(0),SIGINT));
}
+
+Datum pg_logfile_length(PG_FUNCTION_ARGS)
+{
+ extern FILE *logfile; // in elog.c
+
+ if (logfile)
+ PG_RETURN_INT32(ftell(logfile));
+ PG_RETURN_INT32(0);
+}
+
+
+#define MAXLOGFILECHUNK 5
+Datum pg_logfile(PG_FUNCTION_ARGS)
+{
+ size_t size=MAXLOGFILECHUNK;
+ char *buf=0;
+ size_t nbytes;
+
+ char *filename = LogFileName();
+ if (filename)
+ {
+ if (!PG_ARGISNULL(0))
+ size = PG_GETARG_INT32(0);
+ if (size MAXLOGFILECHUNK)
+ {
+ size = MAXLOGFILECHUNK;
+ ereport(WARNING,
+ (errcode(ERRCODE_OUT_OF_MEMORY),
+ errmsg(Maximum size is %d.,
MAXLOGFILECHUNK)));
+ }
+
+ FILE *f=fopen(filename, r);
+ if (f)
+ {
+ if (PG_ARGISNULL(1))
+ fseek(f, -size, SEEK_END);
+ else
+ {
+ long pos = PG_GETARG_INT32(1);
+ if (pos = 0)
+ fseek(f, pos, SEEK_SET);
+ else
+ fseek(f, pos, SEEK_END);
+ }
+ buf = palloc(size+1);
+ nbytes = fread(buf, 1, size, f);
+ buf[nbytes] = 0;
+
+ fclose(f);
+ }
+ else
+ {
+ ereport(WARNING,
+ (errcode(ERRCODE_NO_DATA),
+ errmsg(Could not open log file %s.,
filename)));
+ }
+ free(filename);
+ }
+
+ PG_RETURN_CSTRING(buf);
+}
Index: backend/utils/error/elog.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/error/elog.c,v
retrieving revision 1.140
diff -u -r1.140 elog.c
--- backend/utils/error/elog.c3 Jun 2004 02:08:04 -
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
