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)
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:
> 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)
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)
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.
+
+ pg_logfile
+
+
+ pg_logfile_length
+
+
+The functions shown in
+ deal with the server log file if configured with log_destination
+ file.
+previously stored with the COMMENT command. A
+null value is returned if no comment could be found matching the
+specified parameters.
+
+
+
+Server Logfile Functions
+
+
+ Name Return Type
Description
+
+
+
+
+
pg_logfile(size_int4,
offset_int4)
+ cstring
+ get a part of the server log file
+
+
+ pg_logfile_length()
+ int4
+ return the current length of the server log file
+
+
+
+
+
+The pg_logfile 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).
+
+
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 @@
PostgreSQL supports several methods
-for loggning, including stderr and
-syslog. On Windows,
-eventlog is also supported. Set this
+for logging, including stderr,
+file and syslog.
+ On Windows, eventlog is also supported. Set this
option to a list of desired log destinations separated by a
comma. The default is to log to stderr
only. This option must be set at server start.
+
+
+
+ log_filename (string)
+
+
+ This option sets the target filename for the log destination
+ file option. It may be specified as absolute
+ path or relative to the cluster directory.
+
+
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: src/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
--- src/backend/storage/ipc/ipc.c 12 Dec 2003 18:45:09 - 1.87
+++ src/backend/storage/ipc/ipc.c 11 Jun 2004 17:58:52 -
@@ -111,6 +111,8 @@
on_proc_exit_list[on_proc_exit_index].arg);
elog(DEBUG3, "exit(%d)", code);
+
+ LogFileClose();
exit(code);
}
Index: src/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
--- src/backend/utils/adt/misc.c2 Jun 2004 21:29:29 - 1.34
+++ src/backend/utils/adt/misc.c11 Jun 2004 17:58:58 -
@@ -103,3 +103,70 @@
{
PG_RETURN_INT32(pg_signal_backend(PG_GETARG_INT
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)
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)
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)
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. 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. Regards, Andreas ---(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
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)
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)
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)
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
Re: [PATCHES] [HACKERS] serverlog function (log_destination file)
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 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/util
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/ba
