Re: [PATCHES] [GENERAL] ISO week dates

2007-02-13 Thread Peter Eisentraut
Bruce Momjian wrote: > On these questions, we have to find out how Oracle handles it, but > your approach seems appropriate. I don't think Oracle even has that. But personally I'd like to see errors for invalid pattern combinations. -- Peter Eisentraut http://developer.postgresql.org/~petere/

Re: [PATCHES] [HACKERS] Error in from_char() for field 'D'?

2007-02-13 Thread Bruce Momjian
Tom Lane wrote: > "Brendan Jurd" <[EMAIL PROTECTED]> writes: > > However, in from_char(), the reverse is not true. Looking at the code > > snippet above, the digit is scanned straight into tmfc->d unaltered > > (this value is later copied directly to tm->tm_wday circa line 3394). > > Unless I'm mi

Re: [PATCHES] [PERFORM] Direct I/O issues

2007-02-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Not sure if people want this for 8.2. I think we can modify > > test_fsync.c anytime but the movement of the defines into an include > > file is a backend code change. > > I think fooling with this on the day before RC1 is an unreaso

Re: [PATCHES] Avg performance for int8/numeric

2007-02-13 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Ma

Re: [PATCHES] Re: [BUGS] BUG #2724: Could not check connection status with "ssl=on"

2007-02-13 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Bruce Momjian <[EMAIL PROTECTED]> writes: >>> ! if (SOCK_ERRNO != ECONNRESET) >>> ! SSL_shutdown(conn->ssl); >> >> Ummm ... what is this supposed to fix exactly, and what are the odds > I think the user was

Re: [PATCHES] Re: [BUGS] BUG #2724: Could not check connection status with "ssl=on"

2007-02-13 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > ! if (SOCK_ERRNO != ECONNRESET) > > ! SSL_shutdown(conn->ssl); > > Ummm ... what is this supposed to fix exactly, and what are the odds I think the user was getting SIGPIPE on SSL_shutdown() of a closed co

Re: [PATCHES] Re: [BUGS] BUG #2724: Could not check connection status with "ssl=on"

2007-02-13 Thread Tom Lane
Bruce Momjian <[EMAIL PROTECTED]> writes: > ! if (SOCK_ERRNO != ECONNRESET) > ! SSL_shutdown(conn->ssl); Ummm ... what is this supposed to fix exactly, and what are the odds that it will introduce resource leaks? regards, tom lane -

[PATCHES] Re: [BUGS] BUG #2724: Could not check connection status with "ssl=on"

2007-02-13 Thread Bruce Momjian
Based on this report, I have developed the attached patch. Is this OK? The idea is not to call SSL_shutdown() if errno == ECONNRESET. --- ?? wrote: > Hi. > > > I would argue that this is an OpenSSL bu

Re: [PATCHES] psql \lo_* quiet mode patch

2007-02-13 Thread Bruce Momjian
Jeremy Drake wrote: > On Tue, 13 Feb 2007, Bruce Momjian wrote: > > > > > Your patch has been added to the PostgreSQL unapplied patches list at: > > > > http://momjian.postgresql.org/cgi-bin/pgpatches > > > > It will be applied as soon as one of the PostgreSQL committers reviews > > and approv

Re: [PATCHES] psql \lo_* quiet mode patch

2007-02-13 Thread Jeremy Drake
On Tue, 13 Feb 2007, Bruce Momjian wrote: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > It will be applied as soon as one of the PostgreSQL committers reviews > and approves it. This one has also already be

Re: [PATCHES] psql \lo_* quiet mode patch

2007-02-13 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Je

Re: [PATCHES] [GENERAL] ISO week dates

2007-02-13 Thread Bruce Momjian
Brendan Jurd wrote: > I'd also like to raise the topic of how conversion from text to ISO > week dates should be handled, where the user has specified a bogus > mixture of fields. Existing code basically ignores these issues; for > example, if a user were to call to_date('1998-01-01 2454050', > 'Y

Re: [PATCHES] [GENERAL] ISO week dates

2007-02-13 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Br

Re: [PATCHES] array_accum aggregate

2007-02-13 Thread Bruce Momjian
What is the status of this feature addition? --- Stephen Frost wrote: -- Start of PGP signed section. > * Tom Lane ([EMAIL PROTECTED]) wrote: > > (However, now that we support nulls in arrays, meseems a more consistent > > d

Re: [PATCHES] [HACKERS] Another aspect of set_ps_display ()

2007-02-13 Thread Bruce Momjian
I did some research on this item from October, 2006. I was struck by the memset of 2344 for every proc title change on popular platforms like Linux. The attached patch reduces the memset to only span the length needed since the last title change. This should significantly reduce the proc title

Re: [PATCHES] Forbid finishing a prepared transaction from another database

2007-02-13 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Throw an error if you try to COMMIT/ROLLBACK PREPARED from a database > other than the one where the transaction was originally prepared. Committed, but I made it ERRCODE_FEATURE_NOT_SUPPORTED, since this seems to me to be in the nature of somethin

Re: [PATCHES] Enums patch v2

2007-02-13 Thread Tom Dunstan
Neil Conway wrote: On Thu, 2007-02-01 at 22:50 -0500, Bruce Momjian wrote: Where are we on this? I can commit to reviewing this. The patch looked fairly solid on a quick glance through, but I won't have the cycles to review it properly for a week or two. I've brought this up to date with the

[PATCHES] Forbid finishing a prepared transaction from another database

2007-02-13 Thread Heikki Linnakangas
Here's a patch to: Throw an error if you try to COMMIT/ROLLBACK PREPARED from a database other than the one where the transaction was originally prepared. This needs to be fixed because at least NOTIFY/LISTEN gets confused, and sends the notification to the database where the commit is done,

Re: [PATCHES] [GENERAL] contrib/levenshtein() has a bug?

2007-02-13 Thread Bruce Momjian
Tom Lane wrote: > Ben <[EMAIL PROTECTED]> writes: > > The levenshtein function from contrib/fuzzystrmatch.sql has a max arg > > length of 255. OK, that's cool. But check this out: > > > mbrainz_db=> select max(length(name)) from public.track; > > max > > - > > 255 > > (1 row) > > > mbrai

Re: [PATCHES] tiny patch to make vacuumdb -a's database order match pg_dumpall

2007-02-13 Thread Bruce Momjian
Dan Thomas wrote: > Hiya, > > I've been having trouble running vacuumdb -a and pg_dumpall > concurrently because they run through the databases in a different > order (so dumpall was getting stuck behind vacuum's lock, and my > firewall was rather unhelpfully closing the idle connection). I can't

Re: [PATCHES] Have psql show current sequnce values - (Resubmission)

2007-02-13 Thread Bruce Momjian
Patch removed from queue based on patch review. Resubmit. --- Dhanaraj M wrote: > > Sorry for resubmitting this patch. > Just now I found a problem. > Instead of assigning initial sequence value to 1, > I assign LLONG_MAX

Re: [HACKERS] [PATCHES] Have psql show current sequnce values - (Resubmission)

2007-02-13 Thread Bruce Momjian
Based on this patch review, I am removing the patch from the patch queue and requiring a resubmission. --- Tom Lane wrote: > Dhanaraj M <[EMAIL PROTECTED]> writes: > > Sorry for resubmitting this patch. > > Just now I found

Re: [PATCHES] New features for pgbench

2007-02-13 Thread Magnus Hagander
On Tue, Feb 13, 2007 at 01:08:04AM -0500, Greg Smith wrote: > On Tue, 13 Feb 2007, Takayuki Tsunakawa wrote: > > >The Win32 APIs that pgbench is using for gettimeofday() (in > >src/port/gettimeofday.c) is much lower in resolution than Linux. > > I wasn't aware of this issue, and it certainly mak