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 de
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
>
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 2004-08-2
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
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), a
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_fil
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 th
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_l
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 somet
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-%
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 behav
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 xx
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.
>
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
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 rotati
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:
+ changes postgresql.conf option 'log_filename_prefix' to 'log_filename',
and adds strftime() escape interpolation;
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 ro
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 wi
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
> >
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
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 arg
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
On Monday September 20 2004 5:39, Tom Lane wrote:
> "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
> > u
On Monday September 20 2004 5:45, Ed L. wrote:
> On Monday September 20 2004 5:39, Tom Lane wrote:
> > "Ed L." <[EMAIL PROTECTED]> writes:
> > > + /*
> > > + * We expect a strftime(%z) result of the form "[+-]HHMM"
> > > acc
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)?
>
>
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 queries
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. Perhap
> > > 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 Thursday January 27 2005 12:08, Neil Conway wrote:
> On Thu, 2005-01-27 at 08:05 +0100, Michael Paesold wrote:
> > Perhaps you could rename indices_size to indexes_size.
>
> Yeah, sorry -- forgot to mention that. I believe we decided to
> standardize on "indexes" as the plural of "index" (at lea
> > 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: contrib/d
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_r
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
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.
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.
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
ret
39 matches
Mail list logo
