Re: [PATCHES] serverlog rotation/functions
От | Andreas Pflug |
---|---|
Тема | Re: [PATCHES] serverlog rotation/functions |
Дата | |
Msg-id | 40F6D881.1080709@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: [PATCHES] serverlog rotation/functions (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [PATCHES] serverlog rotation/functions
|
Список | pgsql-hackers |
Bruce Momjian wrote: > > I don't see any reason to have a pattern though I suppose if you mix > pgsql log files in with other log files it might be a problem. One idea > would be for the client-side program to do some processing like this: > > SELECT * > FROM dir_listing('/var/log') AS dir > WHERE dir LIKE 'pgsql_%' > > or something like that where the client pulls apart the directory > specifiction like this: > > log_dest = '/var/log/postgresql.log.%Y-%m-%d_%H%M%S' > > You do something that splits the value into directory name and file name > and removes every letter after %. > > /var/log > postgresql.log.%-%-%_%%% > > Another idea is to allow filename wildcards in the listing so it > becomes: > > SELECT * > FROM dir_listing('/var/log/postgresql.log.*-*-*_***') AS dir > > While that is nice, it doesn't match the functionality of opendir so we > are perhaps better with one that doesn't handle wildcards and we just do > the wildcard processing in the WHERE clause. Uh, this looks ugly. How about pg_logfile_list() RETURNS setof timestamp -- to list available logfiles pg_logfile_filename(timestamp) to return filename for that logfile and generic pg_dir(wildcard_text) pg_file_length(filename_text) pg_file_read(filename_text, offs, len) pg_file_write(filename_text, contents_text) pg_file_delete(filename) I'd like to have the logfile api straigt forward. I finally would like all server logging to go into a non-configurable DataDir subdirectory pg_log with filenames mangled by internal rules. Maybe it's a good idea to have the pid in the filename too, to detect postmaster restarts. > > Once we do this there will not be any backend writing to those files. Of course not, only the logging subprocess may write. > (We will need the log subprocess pid in shared memory so backends can > send signals to it.) Yes, because the inherited SysLoggerPID might become invalid in case the logger process crashes and is recreated. I am not sure how we will do file deletes but I > think each backend will have to do the delete itself rather than try to > pass the file name to the log process. Agreed. I think we will have to assume > the log file names increase in ordering so we know which one is the > current one. I can't think if a cleaner way to communicate this to the > backends except perhaps as you suggest as shared memory areas that > contains the name, but we will need a lock so the backends don't read it > while it is changing. That would be a nice feature. We can omit this, if we supply only a native function. In that case, it's up to the admin not to shoot himself into the foot. > > Sorry to be dumping more work on you but I think this is a better > directory to go for this feature. Well that's the pain with you cvs committers guys :-) Regards, Andreas
В списке pgsql-hackers по дате отправления: