log_filename_prefix --> log_filename + strftime()

Started by Ed L.almost 22 years ago54 messagespatches
Jump to latest
#1Ed L.
pgsql@bluepolka.net

Attached is a patch which replaces the 'log_filename_prefix' configuration
directive with a similar 'log_filename' directive. It differs from the
former in the following ways:

	+ allows embedded strftime() escapes ala Apache's rotatelogs;
	+ eliminates hard-coded embedding of the postmaster pid;
	+ makes the current hard-coded timestamp configurable;
	+ changes the default log filename to exclude the PID;

This patch enables us to continue using our existing log-handling utilities
and filenaming conventions which we now use with Apache's rotatelogs.

Attachments:

patches.difftext/x-diff; charset=us-ascii; name=patches.diffDownload+64-57
#2Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#1)
Re: log_filename_prefix --> log_filename + strftime()

The patch is intended for 8.0.0 or later, and was generated and tested with
the cvs trunk as of 26-Aug-2004.

Show quoted text

On Friday August 27 2004 11:50, Ed L. wrote:

Attached is a patch which replaces the 'log_filename_prefix'
configuration directive with a similar 'log_filename' directive. It
differs from the former in the following ways:

+ allows embedded strftime() escapes ala Apache's rotatelogs;
+ eliminates hard-coded embedding of the postmaster pid;
+ makes the current hard-coded timestamp configurable;
+ changes the default log filename to exclude the PID;

This patch enables us to continue using our existing log-handling
utilities and filenaming conventions which we now use with Apache's
rotatelogs.

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#1)
Re: log_filename_prefix --> log_filename + strftime()

"Ed L." <pgsql@bluepolka.net> writes:

Attached is a patch which replaces the 'log_filename_prefix' configuration
directive with a similar 'log_filename' directive.
+ changes the default log filename to exclude the PID;

This would be better stated as "makes it impossible to use the PID
in the file name". While I'm prepared to grant that it may not be
necessary to do so in many scenarios, I'm not very happy with
arbitrarily removing the ability ... especially without giving any
justification.

regards, tom lane

#4Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#3)
Re: log_filename_prefix --> log_filename + strftime()

On Friday August 27 2004 12:08, Tom Lane wrote:

"Ed L." <pgsql@bluepolka.net> writes:

Attached is a patch which replaces the 'log_filename_prefix'
configuration directive with a similar 'log_filename' directive.
+ changes the default log filename to exclude the PID;

This would be better stated as "makes it impossible to use the PID
in the file name". While I'm prepared to grant that it may not be
necessary to do so in many scenarios, I'm not very happy with
arbitrarily removing the ability ... especially without giving any
justification.

Yes, should have said more on that item. First, I didn't see how to easily
make it configurable in combination with strftime() without doing more
work, and it didn't appear to be worth the effort. By its addition,
hard-coding the PID into the filename deviates from what I would argue is
the de facto standard of Apache's rotatelogs and forces a naming convention
where none existed before. That creates work for us as we have a
considerable infrastructure setup to deal with logs; I suspect that may be
the case with others. I looked, but did not find, justification for why it
was introduced; I would assume it was added to allow for multiple
postmasters sharing the same log directory. I had difficulty fathoming the
usefulness of this being hard-coded, as it seems one could compensate
easily through the configurable 'log_filename' if one chose to share a log
directory among postmasters. Not by including the PID, but by some other
postmaster-unique naming approach. Given its a new 'feature', I'm hoping
it can be altered to return the freedom of filenaming to the administrator.

#5Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#4)
Re: log_filename_prefix --> log_filename + strftime()

"Ed L." <pgsql@bluepolka.net> writes:

On Friday August 27 2004 12:08, Tom Lane wrote:

[ justification please ]

Yes, should have said more on that item. First, I didn't see how to easily
make it configurable in combination with strftime() without doing more
work, and it didn't appear to be worth the effort. By its addition,
hard-coding the PID into the filename deviates from what I would argue is
the de facto standard of Apache's rotatelogs and forces a naming convention
where none existed before. That creates work for us as we have a
considerable infrastructure setup to deal with logs; I suspect that may be
the case with others. I looked, but did not find, justification for why it
was introduced; I would assume it was added to allow for multiple
postmasters sharing the same log directory. I had difficulty fathoming the
usefulness of this being hard-coded, as it seems one could compensate
easily through the configurable 'log_filename' if one chose to share a log
directory among postmasters. Not by including the PID, but by some other
postmaster-unique naming approach. Given its a new 'feature', I'm hoping
it can be altered to return the freedom of filenaming to the administrator.

Or you could use different log_directory settings for different PMs.
Fair enough.

Anyone else have an opinion pro or con about this change? IMHO it's in
the gray area between bug fix and feature addition. If we want to do
it, though, doing it now is certainly better than holding it for 8.1,
since by then people would have gotten used to the present behavior.

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or
would something different be closer to the common practice with Apache?

regards, tom lane

#6Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#5)
Re: log_filename_prefix --> log_filename + strftime()

On Friday August 27 2004 12:41, Tom Lane wrote:

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or
would something different be closer to the common practice with Apache?

Apache defaults to access_log.N where N is the epoch of the logfile start
time.

Ed

#7Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#5)
Re: log_filename_prefix --> log_filename + strftime()

Tom Lane wrote:

"Ed L." <pgsql@bluepolka.net> writes:

On Friday August 27 2004 12:08, Tom Lane wrote:

[ justification please ]

Yes, should have said more on that item. First, I didn't see how to easily
make it configurable in combination with strftime() without doing more
work, and it didn't appear to be worth the effort. By its addition,
hard-coding the PID into the filename deviates from what I would argue is
the de facto standard of Apache's rotatelogs and forces a naming convention
where none existed before. That creates work for us as we have a
considerable infrastructure setup to deal with logs; I suspect that may be
the case with others. I looked, but did not find, justification for why it
was introduced; I would assume it was added to allow for multiple
postmasters sharing the same log directory. I had difficulty fathoming the
usefulness of this being hard-coded, as it seems one could compensate
easily through the configurable 'log_filename' if one chose to share a log
directory among postmasters. Not by including the PID, but by some other
postmaster-unique naming approach. Given its a new 'feature', I'm hoping
it can be altered to return the freedom of filenaming to the administrator.

Or you could use different log_directory settings for different PMs.
Fair enough.

Anyone else have an opinion pro or con about this change? IMHO it's in
the gray area between bug fix and feature addition. If we want to do
it, though, doing it now is certainly better than holding it for 8.1,
since by then people would have gotten used to the present behavior.

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or
would something different be closer to the common practice with Apache?

If the PID isn't there is there a danger of different postmasters
clobbering each other's logs? ISTM having the PID there gives some sort
of guarantee that that won't happen. I don't have any strong opinion one
way or another, but I wondered if a configurable strings with % escapes
like we use for log_line_prefix might be better. It could be argued to
be overkill, I guess. Alternatively, we could have a different boolean
option 'log_filename_use_pid' or some such.

cheers

andrew

#8Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#6)
Re: log_filename_prefix --> log_filename + strftime()

On Friday August 27 2004 12:51, Ed L. wrote:

On Friday August 27 2004 12:41, Tom Lane wrote:

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or
would something different be closer to the common practice with Apache?

Apache defaults to access_log.N where N is the epoch of the logfile start
time.

I should say, Apache rotatelogs takes a configurable filename and then
appends ".N" where N is the logfile start time epoch. In one case, its
access_log.N, in another its error_log.N.

Ed

#9Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andrew Dunstan (#7)
Re: log_filename_prefix --> log_filename + strftime()

Andrew Dunstan <andrew@dunslane.net> writes:

If the PID isn't there is there a danger of different postmasters
clobbering each other's logs?

Only if they're logging into the same directory with the same filename
pattern. This isn't the default (the default log_directory is under
$PGDATA), and so I'm not that worried now that I think about it carefully.
I'm coming around to agree with Ed's position that it's not worth the
trouble to provide more than the strftime escapes.

regards, tom lane

#10Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#8)
Re: log_filename_prefix --> log_filename + strftime()

"Ed L." <pgsql@bluepolka.net> writes:

On Friday August 27 2004 12:41, Tom Lane wrote:

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or
would something different be closer to the common practice with Apache?

I should say, Apache rotatelogs takes a configurable filename and then
appends ".N" where N is the logfile start time epoch. In one case, its
access_log.N, in another its error_log.N.

Hmm ... there isn't any way to emulate that with strftime escapes,
unless I missed the right one.

regards, tom lane

#11Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#10)
Re: log_filename_prefix --> log_filename + strftime()

On Friday August 27 2004 1:03, Tom Lane wrote:

"Ed L." <pgsql@bluepolka.net> writes:

On Friday August 27 2004 12:41, Tom Lane wrote:

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense,
or would something different be closer to the common practice with
Apache?

I should say, Apache rotatelogs takes a configurable filename and then
appends ".N" where N is the logfile start time epoch. In one case, its
access_log.N, in another its error_log.N.

Hmm ... there isn't any way to emulate that with strftime escapes,
unless I missed the right one.

If you supply an escape, Apache will override that default epoch. So I
could see setting the default to "server_log" or "postgresql_log" or
whatever, and making the default (with no escapes supplied) be the epoch.
That would be easy tweak, and be much closer to Apache style.

Ed

Apache 1.3.31:

if (use_strftime) {
struct tm *tm_now;
tm_now = gmtime(&tLogStart);
strftime(buf2, sizeof(buf2), szLogRoot, tm_now);
}
else {
sprintf(buf2, "%s.%010d", szLogRoot, (int) tLogStart);
}

#12Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#3)
Re: log_filename_prefix --> log_filename + strftime()

Tom Lane wrote:

"Ed L." <pgsql@bluepolka.net> writes:

Attached is a patch which replaces the 'log_filename_prefix' configuration
directive with a similar 'log_filename' directive.
+ changes the default log filename to exclude the PID;

This would be better stated as "makes it impossible to use the PID
in the file name". While I'm prepared to grant that it may not be
necessary to do so in many scenarios, I'm not very happy with
arbitrarily removing the ability ... especially without giving any
justification.

I don't have the time now to review the impact, but this might make
interpreting the log filename difficult or impossible, effectively
corrupting pg_logdir_ls.
I don't object against adjusting the timestamp format in a reasonable
way, but it should stay fixed; same about PID.

Regards,
Andreas

#13Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#11)
Re: log_filename_prefix --> log_filename + strftime()

"Ed L." <pgsql@bluepolka.net> writes:

On Friday August 27 2004 1:03, Tom Lane wrote:

Hmm ... there isn't any way to emulate that with strftime escapes,
unless I missed the right one.

If you supply an escape, Apache will override that default epoch. So I
could see setting the default to "server_log" or "postgresql_log" or
whatever, and making the default (with no escapes supplied) be the epoch.
That would be easy tweak, and be much closer to Apache style.

Yeah, and it would also prevent a risk I now see with your initial
patch: if no %, it'll write the same filename each time, which
is almost certainly not desired. Works for me.

regards, tom lane

#14Andrew Dunstan
andrew@dunslane.net
In reply to: Tom Lane (#10)
Re: log_filename_prefix --> log_filename + strftime()

Tom Lane wrote:

"Ed L." <pgsql@bluepolka.net> writes:

On Friday August 27 2004 12:41, Tom Lane wrote:

BTW, as long as we are taking Apache as the de facto standard --- does
the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or
would something different be closer to the common practice with Apache?

I should say, Apache rotatelogs takes a configurable filename and then
appends ".N" where N is the logfile start time epoch. In one case, its
access_log.N, in another its error_log.N.

Hmm ... there isn't any way to emulate that with strftime escapes,
unless I missed the right one.

According to my Linux man page, the Olsen library has %s for that. I
don't see it in src/timezone/strftime.c, though

cheers

andrew

#15Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andreas Pflug (#12)
Re: log_filename_prefix --> log_filename + strftime()

Andreas Pflug <pgadmin@pse-consulting.de> writes:

I don't have the time now to review the impact, but this might make
interpreting the log filename difficult or impossible, effectively
corrupting pg_logdir_ls.

So if you want to use that, you use a format that it can cope with.
I don't see a problem.

(This is probably an OK reason to keep the default log_filename in
Y/M/D/H/M/S style, though, rather than ".epoch" style.)

regards, tom lane

#16Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#15)
Re: log_filename_prefix --> log_filename + strftime()

Tom Lane wrote:

Andreas Pflug <pgadmin@pse-consulting.de> writes:

I don't have the time now to review the impact, but this might make
interpreting the log filename difficult or impossible, effectively
corrupting pg_logdir_ls.

So if you want to use that, you use a format that it can cope with.
I don't see a problem.

(This is probably an OK reason to keep the default log_filename in
Y/M/D/H/M/S style, though, rather than ".epoch" style.)

Ah, so we keep the existing format but drop the pid, and just make it
changable by the user, and we rename it. Doesn't sound as drastic as it
first did.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#17Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#16)
Re: log_filename_prefix --> log_filename + strftime()

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Ah, so we keep the existing format but drop the pid, and just make it
changable by the user, and we rename it. Doesn't sound as drastic as it
first did.

Yeah, the only change in default behavior would be to drop the PID part
of the log filename, which doesn't seem too bad, since people aren't yet
depending on that.

regards, tom lane

#18Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#17)
Re: log_filename_prefix --> log_filename + strftime()

On Friday August 27 2004 1:39, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Ah, so we keep the existing format but drop the pid, and just make it
changable by the user, and we rename it. Doesn't sound as drastic as
it first did.

Yeah, the only change in default behavior would be to drop the PID part
of the log filename, which doesn't seem too bad, since people aren't yet
depending on that.

regards, tom lane

OK, if I read you correctly...

Default remains "postgresql-%Y-%m-%d_%H%M%S.log"

(Apache style: access_log.%s)

If log_filename = 'xxx', rotate with strftime() to 'xxx-%Y-%m-%d_%H%M%S'

(Apache style: xxx.%s)

If log_filename = 'xxx.%a', rotate with strftime() to 'xxx.%a'

(Apache style: xxx.%a)

Not a big fan of the verbose 32-character default name, 'server_log.%s'
would be my pick, but easy enough to override it.

Ed

#19Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#18)
Re: log_filename_prefix --> log_filename + strftime()

"Ed L." <pgsql@bluepolka.net> writes:

If log_filename = 'xxx', rotate with strftime() to 'xxx-%Y-%m-%d_%H%M%S'

No, I was thinking that if no %'s in the log_filename, then use xxx.EPOCH
to provide Apache compatibility.

regards, tom lane

#20Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#19)
Re: log_filename_prefix --> log_filename + strftime()

On Friday August 27 2004 2:15, Tom Lane wrote:

"Ed L." <pgsql@bluepolka.net> writes:

If log_filename = 'xxx', rotate with strftime() to
'xxx-%Y-%m-%d_%H%M%S'

No, I was thinking that if no %'s in the log_filename, then use xxx.EPOCH
to provide Apache compatibility.

OK, that works for me.

One addition I'd like to include with the revised patch: a boolean
postgresql.conf option ('log_truncate_on_rotation', default false) to
truncate any existing log file by the same name. Default behavior here and
with Apache is to always append, but it's a useful feature for us because
it largely eliminates the issue of logs filling up the disk. You don't
want the log clobbered on restarts, so the idea is to only truncate during
time/size-based rotation, not on the initial open. Thoughts?

Ed

#21Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#13)
#22Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#20)
#23Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#21)
#24Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#22)
#25Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#24)
#26Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#16)
#27Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#22)
#28Bruce Momjian
bruce@momjian.us
In reply to: Ed L. (#1)
#29Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#26)
#30Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#28)
#31Jan Wieck
JanWieck@Yahoo.com
In reply to: Tom Lane (#5)
#32Jan Wieck
JanWieck@Yahoo.com
In reply to: Andreas Pflug (#29)
#33Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Jan Wieck (#32)
#34Tom Lane
tgl@sss.pgh.pa.us
In reply to: Andreas Pflug (#33)
#35Jan Wieck
JanWieck@Yahoo.com
In reply to: Tom Lane (#34)
#36Tom Lane
tgl@sss.pgh.pa.us
In reply to: Jan Wieck (#35)
#37Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#36)
#38Ed L.
pgsql@bluepolka.net
In reply to: Bruce Momjian (#28)
#39Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#38)
#40Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#39)
#41Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#40)
#42Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Tom Lane (#15)
#43Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#39)
#44Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#43)
#45Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#40)
#46Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#45)
#47Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#45)
#48Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#47)
#49Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#45)
#50Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#49)
#51Ed L.
pgsql@bluepolka.net
In reply to: Ed L. (#50)
#52Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#51)
#53Ed L.
pgsql@bluepolka.net
In reply to: Tom Lane (#52)
#54Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ed L. (#53)