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/
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
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
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
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
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
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
-
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
23 matches
Mail list logo