Hi all,
my next TODO item for the Win32 port was to try to bring all the regression
tests up.
Pleased to report that, with a great deal of hackage + kludges (which I hope
to refine and submit as patches for review over the next couple weeks), all
but 10 tests pass!
7 of these fail pretty much
Hi,
On Tuesday 24 February 2004 12:11, Claudio Natoli wrote:
Hi all,
my next TODO item for the Win32 port was to try to bring all the regression
tests up.
Pleased to report that, with a great deal of hackage + kludges (which I
hope to refine and submit as patches for review over the next
Claudio Natoli said:
7 of these fail pretty much *only* due to localtime returning NULL for
pre-1970 dates, specifically: date, timestamp, timestampz, abstime,
tinterval, horology, arrays. To resolve this, seems like there are 3
solutions:
a) Provide post-1970-only versions of the expected
http://www.osnews.com/printer.php?news_id=6136
Shridhar
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
Maybe there should be a provision similar to the stats collector's
check-for-read-ready-from-a-pipe?
the case of the bgwriter is a bit of a twist here. In contrast to the
collectors it is connected to the shared memory. So it
Hi,
I've already subscribed my e-mail address to the
pgsql-hackers.
The method I've used to convert DBMirror to a
peer-to-peer replicator was two DBMirror instances
with one considered slave of other as the master.
Here, I've stopped the loop back by dropping the
trigger when INSERT, DELETE,
I will look at c) unless someone comes up with a better idea
or someone else gets in first.
That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public domain... needs a
closer look that I've given it, but might be a good starting point.
I will look at c) unless someone comes up with a better idea
or someone else gets in first.
That would be great. Grab a hold of the cygwin sources.
winsup/cygwin/localtime.cc claims that it is in the public
domain... needs a closer look that I've given it, but might be a
good
Andrew Dunstan [EMAIL PROTECTED] writes:
Claudio Natoli said:
a) Provide post-1970-only versions of the expected regression test
output, for use under win32
b) Remove pre-1970 dates from *all* regression test files
c) Code up pg_localtime for win32
I don't think a) and b) are options at all
Claudio Natoli [EMAIL PROTECTED] writes:
The join and rules failures don't look material, AFAICS, as the right rows
are returned, just not necessarily in the expected order... is this an
issue? Is the order mandated in these cases. Again, afaIcs, it isn't, but
strictly I'm out of my depth
George Weaver wrote:
I'm not sure of the detail behind winsup/cygwin/localtime.cc, but there are
problems with how Cygwin handles dates and times on Windows.
See http://www.cygwin.com/ml/cygwin/2003-07/msg01016.html.
If there is any relevance, I think it is imperative that the Win32 version
of
I have 2 small questions.
1. Is there any reason to exclude underscore as the first char of a
dollar quoting delimiter (after the $), e.g. $_foo_$? I'm happy either
way, just want to be as liberal as is reasonable.
2. David Fetter asked me the other day if there was any limit on the
length of
On Tuesday 24 February 2004 21:15, scott.marlowe wrote:
On Tue, 24 Feb 2004, Shridhar Daithankar wrote:
http://www.osnews.com/printer.php?news_id=6136
That page gets a please don't link to printer ready pages error and
redirects to here:
http://www.osnews.com/story.php?news_id=6136
My
On Tue, 24 Feb 2004, Shridhar Daithankar wrote:
http://www.osnews.com/printer.php?news_id=6136
That page gets a please don't link to printer ready pages error and
redirects to here:
http://www.osnews.com/story.php?news_id=6136
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
1. Is there any reason to exclude underscore as the first char of a
dollar quoting delimiter (after the $), e.g. $_foo_$? I'm happy either
way, just want to be as liberal as is reasonable.
I think we had agreed to same rules as identifiers, except for
Title: Message
http://www.phpbuilder.com/columns/smith20010821.php3?page=3
Dann Corbit wrote:
http://www.phpbuilder.com/columns/smith20010821.php3?page=3
bigint indexes work fine. The queries probably referenced 32-bit
integer constants that were neither quoted nor CAST. I always start
bigint sequences at 5 billion. This ensures that client applications
aren't
-Original Message-
From: Mike Mascari [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 24, 2004 3:27 PM
To: Dann Corbit
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Is indexing broken for bigint columns?
Dann Corbit wrote:
Dann Corbit wrote:
http://www.phpbuilder.com/columns/smith20010821.php3?page=3
http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-INT
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
-Original Message-
From: Peter Eisentraut [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 24, 2004 3:38 PM
To: Dann Corbit; PostgreSQL-development
Subject: Re: [HACKERS] Is indexing broken for bigint columns?
Dann Corbit wrote:
Dann Corbit wrote:
PostgreSQL is the only database that requires casts to do an index
lookup.
Possibly (quite probably) true, but you don't show any evidence that
SQL*Server, Oracle, or MySQL uses indexes either. Like I said
before, Tom (of course) already has a fix is already in the
Dann Corbit wrote:
Dann Corbit wrote:
http://www.phpbuilder.com/columns/smith20010821.php3?page=3
http://www.postgresql.org/docs/7.4/static/datatype.html#DATATYPE-INT
PostgreSQL is the only database that requires casts to do an index
lookup.
This issue has been discussed on these
Why? You can reconstruct it with a simple ANALYZE command. Dumping
and restoring would mean nailing down cross-version assumptions about
what it contains, which doesn't seem real forward-looking...
I seem to recall that people like that kind of thing so that the dump is
really the current state
Jan Wieck [EMAIL PROTECTED] writes:
In the case of a postmaster crash, I think something in the system
is so wrong that I'd prefer an immediate shutdown.
I agree. Allowing existing backends to commit transactions after the
postmaster has died doesn't strike me as being that useful, and is
Shelby Cain [EMAIL PROTECTED] writes:
The select statements return different data for
most_commons_vals depending on whether n_distinct is
included in the select clause or not.
I only seem to get the behavior below against int8
columns - but I haven't interated through every
conceivable data
Tom Lane wrote:
Hoo, I'm surprised no one noticed this during 7.4 development/testing.
The problem applies for any datatype that requires double alignment,
which includes int8, float8, and timestamp as well as most of the
geometric types. pg_statistic is declared as using type anyarray,
and this
Joe Conway [EMAIL PROTECTED] writes:
anyarray has been defined this way since 7.3 -- any concerns there?
I don't think so --- we weren't trying to use it as an actual column
datatype back then.
7.4 has a problem though :-( ... this is one of the damn I wish we'd
caught that before release ones,
I don't think so --- we weren't trying to use it as an actual column
datatype back then.
7.4 has a problem though :-( ... this is one of the damn I wish we'd
caught that before release ones, since it can't easily be fixed without
initdb. Reminds me that I need to get to work on making pg_upgrade
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Has anyone given any thought as to whether dumping and restoring
pg_statistic is worthwhile?
Why? You can reconstruct it with a simple ANALYZE command. Dumping
and restoring would mean nailing down cross-version assumptions about
what it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've written a summary of my findings on implementing and using
materialized views in PostgreSQL. I've already deployed eagerly updating
materialized views on several views in a production environment for a
company called RedWeek:
On Tuesday 24 February 2004 16:11, Jonathan M. Gardner wrote:
I've written a summary of my findings on implementing and using
materialized views in PostgreSQL. I've already deployed eagerly updating
materialized views on several views in a production environment for a
company called RedWeek:
Richard Huxton wrote:
On Tuesday 24 February 2004 16:11, Jonathan M. Gardner wrote:
I've written a summary of my findings on implementing and using
materialized views in PostgreSQL. I've already deployed eagerly updating
materialized views on several views in a production environment for a
On Tue, 2004-02-24 at 12:11, Richard Huxton wrote:
On Tuesday 24 February 2004 16:11, Jonathan M. Gardner wrote:
I've written a summary of my findings on implementing and using
materialized views in PostgreSQL. I've already deployed eagerly updating
materialized views on several views in
33 matches
Mail list logo
