On Monday August 30 2004 11:07, Ed L. wrote:
On Monday August 30 2004 10:56, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
Attached is a revised patch:
Applied with minor revisions.
I did not add UTC offset logic nor logic to shift to top of the
hour/day for rotation periods of
On Monday September 20 2004 4:43, Ed L. wrote:
This patch rotates logs on local time boundaries instead of UTC
boundaries, e.g., midnight local for daily rotation instead of midnight
UTC. It does so by parsing the %z result from strftime().
... I am arguing for
inclusion of this patch
Ed L. [EMAIL PROTECTED] writes:
Consider the case if one is
truncating logs on rotation and rotating hourly. UTC vs local is
irrelevant. If local time shifts backward from 02:00 to 01:00, our UTC
offset will move in the negative direction. If 1) our policy were to
truncate on rotation,
On Monday September 20 2004 4:57, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
Consider the case if one is
truncating logs on rotation and rotating hourly. UTC vs local is
irrelevant. If local time shifts backward from 02:00 to 01:00, our UTC
offset will move in the negative
Ed L. [EMAIL PROTECTED] writes:
+ /*
+ * We expect a strftime(%z) result of the form [+-]HHMM according to
+ * RFC822-conformant dates, where HH:MM is the unsigned UTC offset.
+ * If we don't get it, just return zero offset, and let the logs
+ * rotate on UTC time
Ed L. [EMAIL PROTECTED] writes:
That might work for you, but it's not portable.
Do you consider pg_tm.tm_gmtoff reliable and portable from
pg_localtime(now)?
Yeah, in fact I was just adapting the patch to use that.
regards, tom lane
---(end
On Monday September 20 2004 6:02, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
That might work for you, but it's not portable.
Do you consider pg_tm.tm_gmtoff reliable and portable from
pg_localtime(now)?
Yeah, in fact I was just adapting the patch to use that.
I have a 5-line
Ed L. [EMAIL PROTECTED] writes:
I have a 5-line check-last-filename patch, but it's so small you probably
just want to add it yourself?
Yeah, it's pretty trivial. I just applied the attached.
regards, tom lane
Index: syslogger.c
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] 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.
you is the
Should the epoch snprintf format of the int64 pg_time_t timestamp be %lld
instead of %d?
Ed
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Tuesday August 31 2004 8:45, Ed L. wrote:
Should the epoch snprintf format of the int64 pg_time_t timestamp be %lld
instead of %d?
Ah, I see you handled it.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
Ed L. [EMAIL PROTECTED] writes:
On Saturday August 28 2004 9:30, Bruce Momjian wrote:
Are we going to change this before beta2? I have not seen a final
patch yet.
Attached is a revised patch:
Applied with minor revisions.
I did not add UTC offset logic nor logic to shift to top of the
On Monday August 30 2004 10:56, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
Attached is a revised patch:
Applied with minor revisions.
I did not add UTC offset logic nor logic to shift to top of the
hour/day for rotation periods of 60/1440 minutes, but would like to add
that
Ed L. [EMAIL PROTECTED] writes:
One idea for handling the round-to-localtime issue from the other end of the
problem: optionally rotate logs upon an *interpolated* filename change.
The code-as-committed wants to be able to predict the time change in
advance. I'm not totally wedded to that,
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I can see the value of not needing any cron daemon to remove old logs.
No other logs on your system to purge?
The DBA isn't necessarily also root.
Interesting this argument comes from you.. :-)
Tasks like purging old log
Bruce Momjian wrote:
Are we going to change this before beta2? I have not seen a final
patch yet.
Can we have pg_logdir_ls in the backend first so any related changes to
the log filename are reflected in both places?
Otherwise displaying the logfile on the client continues to be a moving
On 8/29/2004 5:12 AM, Andreas Pflug wrote:
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I can see the value of not needing any cron daemon to remove old logs.
No other logs on your system to purge?
The DBA isn't necessarily also root.
Interesting this argument comes
Jan Wieck wrote:
but allows to setup a
configuration that automatically overwrites files in a rotating manner,
if the DBA so desires.
... which can't work because it will overwrite the logfile on server
start, and thus will overwrite the very latest logfile when performing
multiple restarts.
Andreas Pflug [EMAIL PROTECTED] writes:
Jan Wieck wrote:
but allows to setup a
configuration that automatically overwrites files in a rotating manner,
if the DBA so desires.
... which can't work because it will overwrite the logfile on server
start, and thus will overwrite the very
On 8/29/2004 2:06 PM, Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Jan Wieck wrote:
but allows to setup a
configuration that automatically overwrites files in a rotating manner,
if the DBA so desires.
... which can't work because it will overwrite the logfile on server
start, and
Tom Lane wrote:
at logger startup or size-based
rotation, the rule would be to append.
which then has a problem when you startup the postmaster after 10 hours
of downtime ... hmmm.
Doesn't seem like a big problem --- at worst that logfile will get to be
double the size it normally would.
...
Tom Lane wrote:
It's definitely creeping featurism ... but
I can see the value of not needing any cron daemon to remove old logs.
No other logs on your system to purge?
A potential problem is what about size-driven rotation? If the hourly
output exceeds log_rotation_size then you'd truncate and
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
I can see the value of not needing any cron daemon to remove old logs.
No other logs on your system to purge?
The DBA isn't necessarily also root.
regards, tom lane
---(end of
Are we going to change this before beta2? I have not seen a final
patch yet.
---
Ed L. wrote:
Attached is a patch which replaces the 'log_filename_prefix' configuration
directive with a similar 'log_filename' directive.
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
The patch is intended for 8.0.0 or later, and was generated and tested with
the cvs trunk as of 26-Aug-2004.
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
Ed L. [EMAIL PROTECTED] 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
On Friday August 27 2004 12:08, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] 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
Ed L. [EMAIL PROTECTED] 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
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
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
Tom Lane wrote:
Ed L. [EMAIL PROTECTED] 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
Andrew Dunstan [EMAIL PROTECTED] 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
Ed L. [EMAIL PROTECTED] 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?
On Friday August 27 2004 1:03, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] 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
Tom Lane wrote:
Ed L. [EMAIL PROTECTED] 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
Andreas Pflug [EMAIL PROTECTED] 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.
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] 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
Bruce Momjian [EMAIL PROTECTED] 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
On Friday August 27 2004 1:39, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] 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
Ed L. [EMAIL PROTECTED] 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
---(end of
On Friday August 27 2004 2:15, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] 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
On Friday August 27 2004 1:15, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] 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
Ed L. [EMAIL PROTECTED] writes:
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
Ed L. [EMAIL PROTECTED] writes:
On Friday August 27 2004 1:15, Tom Lane wrote:
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.
I think this turns out to be no big
On Friday August 27 2004 3:49, Tom Lane wrote:
A potential problem is what about size-driven rotation? If the hourly
output exceeds log_rotation_size then you'd truncate and rewrite the
current file, which is just exactly not what you want :-(. You could
say that truncation occurs only at
On Friday August 27 2004 4:34, Ed L. wrote:
One other thing I've been thinking of suggesting is that the
next-rotation-target-time be rounded to an exact multiple of
log_rotation_age. So for example if you set log_rotation_age = 60
minutes then rotations will happen at the top of the hour
47 matches
Mail list logo
