Re: [HACKERS] logfile rotation
Bruce Momjian wrote: Actually, this is the current state of this issue. Right, please comment on this. To recall, it uses shared memory for a "switch to next logfile name" flag, which can't cause harm in case of shmem corruption, and a postmaster opened filehandle (kept open) to a dummy file containing the actual file name (pseudo code below). Regards, Andreas --- Andreas Pflug wrote: Tom Lane wrote: Andreas Pflug <[EMAIL PROTECTED]> writes: Answering my own question, the distribution of the current logfile name could be done trough a file handle. would you mind commenting on my suggestion so I can continue on that topic? There is no portable way to redistribute a file handle. Seems I didn't make clear enough what I mean. I'd fopen a file handle in the postmaster, and all subsequent processes will inherit that handle just as they do for stderr; no redistribution required. The log filename is written to that file when pg_logfile_rotate is called: fseek(fh, 0, SEEK_SET); fprintf(fh, "%s", newlogfilname); fflush(); and all subprocesses may retrieve the filename when required by char buf[MAXPGPATH]; fseek(fh, 0, SEEK_SET); fread(buf, 1, MAXPGPATH, fh); buf[MAXPGPATH-1]=0; // prevent buffer overflow logfile=fopen(buf, "a+"); Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logfile rotation
Actually, this is the current state of this issue. --- Andreas Pflug wrote: > Tom Lane wrote: > > >Andreas Pflug <[EMAIL PROTECTED]> writes: > > > > > >>>Answering my own question, the distribution of the current logfile > >>>name could be done trough a file handle. > >>> > >>> > > > > > > > >>would you mind commenting on my suggestion so I can continue on that topic? > >> > >> > > > >There is no portable way to redistribute a file handle. > > > > > > Seems I didn't make clear enough what I mean. > > I'd fopen a file handle in the postmaster, and all subsequent processes > will inherit that handle just as they do for stderr; no redistribution > required. > The log filename is written to that file when pg_logfile_rotate is called: > fseek(fh, 0, SEEK_SET); > fprintf(fh, "%s", newlogfilname); > fflush(); > > and all subprocesses may retrieve the filename when required by > > char buf[MAXPGPATH]; > fseek(fh, 0, SEEK_SET); > fread(buf, 1, MAXPGPATH, fh); > buf[MAXPGPATH-1]=0; // prevent buffer overflow > logfile=fopen(buf, "a+"); > > Regards, > Andreas > > -- 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: [HACKERS] logfile rotation
Tom Lane wrote: Andreas Pflug <[EMAIL PROTECTED]> writes: Answering my own question, the distribution of the current logfile name could be done trough a file handle. would you mind commenting on my suggestion so I can continue on that topic? There is no portable way to redistribute a file handle. Seems I didn't make clear enough what I mean. I'd fopen a file handle in the postmaster, and all subsequent processes will inherit that handle just as they do for stderr; no redistribution required. The log filename is written to that file when pg_logfile_rotate is called: fseek(fh, 0, SEEK_SET); fprintf(fh, "%s", newlogfilname); fflush(); and all subprocesses may retrieve the filename when required by char buf[MAXPGPATH]; fseek(fh, 0, SEEK_SET); fread(buf, 1, MAXPGPATH, fh); buf[MAXPGPATH-1]=0; // prevent buffer overflow logfile=fopen(buf, "a+"); Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logfile rotation
Andreas Pflug <[EMAIL PROTECTED]> writes: >> Answering my own question, the distribution of the current logfile >> name could be done trough a file handle. > would you mind commenting on my suggestion so I can continue on that topic? There is no portable way to redistribute a file handle. regards, tom lane ---(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: [HACKERS] logfile rotation
Andreas Pflug wrote: Andreas Pflug wrote: We agreed long ago that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I understand that, so what's the suggested way to store data common for all backends? Answering my own question, the distribution of the current logfile name could be done trough a file handle. So the only thing remaining in shared mem would be the "reopen logfile" flag, which seems nonproblematic. In case of garbled sharedmem, a backend would reopen the logfile, which does no harm at all, or continue writing the outdated logfile which would be annoying but not harmful either. Acceptable? Tom, would you mind commenting on my suggestion so I can continue on that topic? Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] logfile rotation
Andreas Pflug wrote: We agreed long ago that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I understand that, so what's the suggested way to store data common for all backends? Answering my own question, the distribution of the current logfile name could be done trough a file handle. So the only thing remaining in shared mem would be the "reopen logfile" flag, which seems nonproblematic. In case of garbled sharedmem, a backend would reopen the logfile, which does no harm at all, or continue writing the outdated logfile which would be annoying but not harmful either. Acceptable? Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logfile rotation
Tom Lane wrote: I'll repeat what I said in response to your other posting: Hm? I never posted something with shared mem usage before, what do you mean? This uses a shared memory area with no lock, which seems a bad design; AFAICS there should be no lock necessary. We agreed long ago that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I understand that, so what's the suggested way to store data common for all backends? Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] logfile rotation
Andreas Pflug <[EMAIL PROTECTED]> writes: > Tom doesn't like returning the server's logfile using a pgsql function > unless logfile rotation is implemented, so here it is. I'll repeat what I said in response to your other posting: This uses a shared memory area with no lock, which seems a bad design; but the alternative of having a lock is even worse, since the postmaster would also have to take the lock. We agreed long ago that the postmaster should never depend on the correctness of any shared memory data structure; but this patch would make it do so. I really don't think this is an acceptable solution. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] logfile rotation
Tom doesn't like returning the server's logfile using a pgsql function unless logfile rotation is implemented, so here it is. This proposal doesn't include a daemon that triggers pg_logfile_rotate when appropriate (timestamp and/or length dependent), pg_autovacuum might be a good place to do that. I'd also like to see a table pg_logfile which contains all logfile names, to be able to access older logfiles. Comments? 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 13 Jun 2004 15:57:06 - @@ -7308,6 +7308,80 @@ columns do not have OIDs of their own. + + pg_logfile_get + + + pg_logfile_length + + + pg_logfile_name + + + pg_logfile_rotate + + +The functions shown in + deal with the server log file if configured with log_destination + file. + + + +Server Logfile Functions + + + Name Return Type Description + + + + + pg_logfile_get(size_int4, + offset_int4,filename_text) + cstring + get a part of the current server log file + + + pg_logfile_length(filename_text) + int4 + return the current length of the server log file + + + pg_logfile_rotate() + cstring + rotates the server log file and returns the new log file + name + + + pg_logfile_name() + cstring + returns the current server log file name + + + pg_logfile_rotate() + cstring + rotates the server log file and returns the previous log file + name + + + + + +The pg_logfile_get function will return the + contents of the current server log file, limited by the size + parameter. If size is NULL, a server internal limit (currently + 5) is applied. The position parameter specifies 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). + + +Both pg_logfile_get and + pg_logfile_length have a filename + parameter which may specify the logfile to examine or the + current logfile if NULL. + + 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 13 Jun 2004 15:57:17 - @@ -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 13 Jun 2004 15:57:24 - @@ -727,6 +727,11 @@ reset_shared(PostPortNumber); /* +* Opens alternate log file +*/ + LogFileInit(); + + /* * Estimate number of openable files. This must happen after setting * up semaphores, because on some platforms semaphores count as open * files. 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 13 Jun 2004 15:57:24 - @@ -111,6 +111,8 @@ on_proc_exit_list[on_proc_exit_index].arg); elog(DEBUG3, "exit(%d)", co
