This patch against 8.0.0beta1 source adds log_line_prefix options for
millisecond timestamps (%m), remote host (%h), and remote port (%P). The
milliseconds are useful for QPS measurements, and the remote port is
worthless to us as part of %r.
*** src/backend/utils/error/elog.c.orig
Attached also is a patch to comments in sample postgresql.conf file.
Subject: [PATCHES] log_line_prefix additions
Date: Wednesday August 25 2004 3:26
From: Ed L. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
This patch against 8.0.0beta1 source adds log_line_prefix options for
millisecond timestamps
On Wednesday August 25 2004 4:25, Andrew Dunstan wrote:
From: Ed L. [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
This patch against 8.0.0beta1 source adds log_line_prefix options for
millisecond timestamps (%m), remote host (%h), and remote port (%P).
The milliseconds are useful for QPS
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
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
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
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
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
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
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
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
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
This patch updates log rotation documentation:
+ Removed false statement that log_filename can only be changed on restart
(it is reloadable via sighup);
+ Added a couple of examples;
+ Cleaned up a few smgl tags;
Index: runtime.sgml
On Friday September 17 2004 4:44, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
This patch updates log rotation documentation:
Applied, except for
+ Removed false statement that log_filename can only be changed on
restart (it is reloadable via sighup);
The statement was correct
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
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
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
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 check
The attached patch forces queryless duration log statements to be turned off
in step with the log_statement directive. Without this patch, and with
log_statement = 'mod' and log_duration = true, there is no way to silence
SELECT query duration logging when quieting the logging of SELECT
On Tuesday September 28 2004 7:59, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Your issue brings up that the boolean API doesn't really work well, and
in fact highlights the fact that printing the duration as an
independent capability really made no sense at all. Perhaps your
Shinji Teragaito [EMAIL PROTECTED] writes:
I made a patch to let PostgreSQL work in the LP64 data model on
HP-UX PA-RISC and HP-UX Itanium platform.
I see Shinji's patch changed the library suffix from .sl to .so for ia64.
Is that is necessary? If so, why?
Thanks,
Ed
The attached dbsize patch:
+ makes relation_size(relname) include toast tables;
+ adds aggregate_relation_size(relname) to count table data and indices;
+ adds indices_size(relname) to report the size of indices for a
relation;
I've minimally tested it against PostgreSQL
On Thu, 2005-01-27 at 08:05 +0100, Michael Paesold wrote:
Perhaps you could rename indices_size to indexes_size.
Attached patch identical except for s/indices/indexes/g.
Attached is the same patch as context diff. (prior send from unregistered
email address)
Ed
Index:
On Thursday January 27 2005 6:59, Andreas Pflug wrote:
Neil Conway wrote:
On Tue, 2005-01-25 at 16:49 -0700, Ed L. wrote:
The attached dbsize patch:
+ makes relation_size(relname) include toast tables;
+ adds aggregate_relation_size(relname) to count table data and
indices
On Thursday January 27 2005 2:12, Ed L. wrote:
Well, it seems quite a bit more complicated than that to me, but I'm
going to rework the patch so it drops into 7.3 as well and resubmit
shortly.
Too much trouble for now. Neil, if the latest patch is acceptable or useful
for others
Neil, do you have a verdict on this patch?
On Friday January 28 2005 10:30, Ed L. wrote:
If the C code for the prior dbsize patch is not acceptable for
whatever reason, here's a SQL-based patch to replace it. It's
not a drop-in for 7.3/7.4 as I'd hoped, only an 8.1 patch. I
believe
On Thursday February 3 2005 9:23, Ed L. wrote:
Neil, do you have a verdict on this patch?
On Friday January 28 2005 10:30, Ed L. wrote:
If the C code for the prior dbsize patch is not acceptable
for whatever reason, here's a SQL-based patch to replace it.
I submitted a dbsize patch on Jan
The attached patch overhauls the query planner to store all query
plans and cache all query results in a Microsoft Excel
spreadsheet via ODBC.
Index: postgres.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/tcop/postgres.c,v
On Wednesday April 4 2007 5:37 pm, Bruce Momjian wrote:
Perhaps this could be added to the TODO list? I won't get
to it anytime soon.
Yes. What should the TODO text be?
See if the attached patch is acceptable. If not, perhaps the
TODO text should be:
Enable end user to identify
On Tuesday 01 May 2007 9:34 pm, Tom Lane wrote:
Ed L. [EMAIL PROTECTED] writes:
[ enlarge MAX_REPORTED_DEPS to 2000 ]
I was about to apply this, but stopped to reflect that it is
probably not such a hot idea. My concern is that enormously
long error message detail fields are likely
35 matches
Mail list logo
