FAST PostgreSQL wrote:
I have attempted to do a quick review of the code in this patch, I've
not installed or compiled it. However I do have a couple of comments.
Hi,
Attached is the completed patch for the COPY-able sql log outputs. I have
modified my previous WIP patch, incorporating all t
FAST PostgreSQL wrote:
>> Am Dienstag, 3. April 2007 20:33 schrieb FAST PostgreSQL:
>>> Attached is the completed patch for the COPY-able sql log outputs.
>> Could you please remove random whitespace changes from this patch?
>
> Done and attached.
A couple of comments.
First one that's not at al
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Then, it may be just me, but I find code like this:
> ! sqllogFile = fopen(strcat(filename, ".sql"), "a");
> very hard to read.
Such coding should be rejected out of hand anyway --- can you say
"buffer overrun"?
reg
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Then, it may be just me, but I find code like this:
>> !sqllogFile = fopen(strcat(filename, ".sql"), "a");
>> very hard to read.
>
> Such coding should be rejected out of hand anyway --- can you say
> "buffer overrun"?
I
Peter Eisentraut wrote:
Am Dienstag, 27. März 2007 03:36 schrieb Tom Dunstan:
Here's the current version of the enums patch. Not much change from last
time, the only thought-inducing stuff was fixing up some macros that
changed with the VARLENA changes, and adding a regression test to do
basi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If you want to review or test the feature, the attached patch can be
> used as a replacement for the portion that affects parse_coerce.c, and
> with this it compiles and passes regression. I think it's correct but it
> should still be OKed by at least
>>> Here's the current version of the enums patch.
[ sounds of reviewing... ] Is there a specific reason for
pg_enum.enumname to be type name and not type text? ISTM that type name
wastes space (because most labels will probably be a lot shorter than 63
bytes) and at the same time imposes an imp
Tom Lane wrote:
Here's the current version of the enums patch.
[ sounds of reviewing... ]
(What are those? It's a bit hard to imagine you singing "doo di doo doo"
a la Homer while reviewing )
Is there a specific reason for
pg_enum.enumname to be type name and not type text?
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Is there a specific reason for
>> pg_enum.enumname to be type name and not type text?
> IIRC at one stage Tom wanted to try to make these identifiers, but that
> was quickly abandoned. This might be a hangover from that.
Actually I
These patches have been reasonably tested (and cross-tested) on
Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the native
GSSAPI libraries. They implement the gss-np and (incompletely) the
gss authentication methods. Unlike the current krb5 method gssapi
has native support in J
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Is there a specific reason for
pg_enum.enumname to be type name and not type text?
IIRC at one stage Tom wanted to try to make these identifiers, but that
was quickly abandoned. This might be a hango
Surely your system time is wrong with email dated:
Date: Wed, 4 Apr 2007 18:24:54 +
---
FAST PostgreSQL wrote:
> > Am Dienstag, 3. April 2007 20:33 schrieb FAST PostgreSQL:
> > > Attached is the completed patch
Hi all! Thanks for reviewing the patch!
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Is there a specific reason for
pg_enum.enumname to be type name and not type text?
IIRC at one stage Tom wanted to try to make these identifiers, but that
was quickly abandoned
Tom Lane wrote:
> Unless someone objects, I'll change this and also revert to the
> enumlabel name that seems to have been used originally (it was still
> used in the docs). It seems more readable somehow (I guess it's the
> lack of either ascenders or descenders in "enumname").
The name/text th
Tom Dunstan <[EMAIL PROTECTED]> writes:
> If we ditched the second syscache, we'd want some other way to convert a
> type OID and name into the enum value oid efficiently.
True. OK, never mind that then. I'll still rename it as per your
other comment.
regards, tom lan
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
If you want to review or test the feature, the attached patch can be
used as a replacement for the portion that affects parse_coerce.c, and
with this it compiles and passes regression. I think it's correct but it
should still be OKed b
This patch changes the way pgbench outputs its latency log files so that
every transaction gets a timestamp and notes which transaction type was
executed. It's a one-line change that just dumps some additional
information that was already sitting in that area of code. I also made a
couple of d
Tom Lane wrote:
> Unless someone objects, I'll change this and also revert to the
> enumlabel name that seems to have been used originally (it was still
> used in the docs). It seems more readable somehow (I guess it's the
> lack of either ascenders or descenders in "enumname").
Wow, I wasn't aw
This patch adds the usage count statistic to the information available in
contrib/pgbuffercache. Earlier this month a discussion about my first
attempt to instrument the background writer had Tom asking for details
about the usage histogram I was seeing, and this patch proved to be the
easiest
Possibly minor detail;
from buf_internals.h
uint16usage_count;/* usage counter for clock sweep code */
and you have a int16 to store that. Currently the max buffer count is
5. But is that a complete safe assumption? Maybe a compile time check
that BM_MAX_USAGE_COUNT is < 16k w
On Sun, 1 Apr 2007, Russell Smith wrote:
Currently the max buffer count is 5. But is that a complete safe
assumption? Maybe a compile time check that BM_MAX_USAGE_COUNT is < 16k
would ensure that things don't go wrong?
I actually wasn't even aware that was a hard limit; I just assumed that
BTW, I've got fairly serious problems with a few of the "cuter" parts of
the patch:
enum_first, enum_last: these return ANYENUM but violate the rule that
a polymorphic-result function must have a polymorphic input argument
from which the parser may deduce the actual output type.
enum_range_all: s
This patch puts entries in the log file around some backend events that
regularly cause client pauses, most of which are visible only when running
with log_min_messages = debug2. The main focus is regularly occuring
checkpoints, from either running out of segments or hitting a timeout.
This is
On Thu, 29 Mar 2007, Magnus Hagander wrote:
I've included a couple of more counters per ideas from Greg Smith in his
logging patch.
I just submitted a patch that logs the remaining things of value from my
original that couldn't be derived from the information you're collecting.
Between them
24 matches
Mail list logo
