pgsql-8.1beta2 make check failed on Win32 under MinGW.
Here is some lines from log/initdb.log.
skipped
creating configuration files ... ok
creating template1 database in
C:/MSYS/home/wlzhang/postgresql-8.1beta2/src/test/regress/tmp_check/data/bas
e/1 ... FATAL: syntax error in file
much discussion on collation and ordering
I'm going to take from this discussion that there is no use for the
USING clause with operators not in an operator class and that if this
changes we won't be seriously inconveniencing anybody.
Have a nice day,
--
Martijn van Oosterhout
Bruce Momjian wrote:
Andrew Dunstan wrote:
I'm also unclear why we get two lines at the start of each connection -
that seems like a bug, or is it due to some sort of protocol
negotiation. This is a fresh FC4 machine with only pg 8.0.3 ever installed.
I can not reproduce your
Cool. We look forward to it.On 9/19/05, Mark Dilger [EMAIL PROTECTED] wrote:
Jonah H. Harris wrote: Mark, If you don't mind contributing the changes, we'd be glad to take a look at them.Thanks. -JonahOk, we will post it back soon.We have tested it on two different 64-bit
architectures (Sparc and
The fact that cmpb isn't helping proves that getting the cache line
in a
read-only fashion does *not* do enough to protect the xchgb in this
way.
But maybe another locking instruction would. Comments?
regards, tom lane
Hi, Tom!
Possible you help next link
'Replay:
Le Lundi 19 Septembre 2005 07:38, Peter Eisentraut a écrit :
I think beta 2 is a good time to start fixing up the translations again.
Great :)
I think I'm gonna work on it soon because I'm nearly done with the translation
of the 8.1-beta2 manual.
As I had previously announced, long-time
On Tue, Sep 20, 2005 at 01:17:10PM -0400, Bruce Momjian wrote:
I worked with Jim Nasby and we found this is the line that is failing on
Gerbil in the build farm during initdb: tqual.c, line 844 in 8.0.X
if (HeapTupleHeaderGetCmin(tuple) = snapshot-curcid)
This particular line was
On Thu, Sep 15, 2005 at 11:24:23PM -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Thursday 15 September 2005 15:41, Alvaro Herrera wrote:
Robert Treat reminded me the other day that we don't currently save
pg_autovacuum settings on pg_dump.
ISTM this is a backwards
On Mon, Sep 19, 2005 at 11:09:50PM -0600, Michael Fuhr wrote:
In an earlier message you said that the owner of the machine has
been completely unhelpful about providing any information to track
it down. Is he not responding at all, or is he responding but
with not enough information?
Yes. I
Hi there,
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
Example from real life project - performance of tsearch2 could be
greatly improved if decrease signature size in gistidx.h,
On Mon, Sep 19, 2005 at 10:16:36PM -0400, Bruce Momjian wrote:
Added to TODO:
* Allow DISTINCT to use hashing like GROUP BY
3 lines above we have...
Consider using hash buckets to do DISTINCT, rather than sorting
This would be beneficial when there are few distinct values.
Can you
Oleg Bartunov wrote:
Hi there,
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
According to the docs:
CREATE INDEX is a PostgreSQL language extension. There are no
provisions for
On Tue, Sep 20, 2005 at 11:26:26PM +0400, Oleg Bartunov wrote:
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
As has been pointed out, INDEXes arn't in the SQL spec at all, so you
can
On 8/18/2005 5:14 AM, Qingqing Zhou wrote:
Marc G. Fournier [EMAIL PROTECTED] writes
I've done a grep through the code, to see if its something that we do use,
and
it doesn't seem to come back with anything ... I believe its considered
common knowledge that 'swapping' for a database is evil,
Jim C. Nasby wrote:
On Mon, Sep 19, 2005 at 10:16:36PM -0400, Bruce Momjian wrote:
Added to TODO:
* Allow DISTINCT to use hashing like GROUP BY
3 lines above we have...
Consider using hash buckets to do DISTINCT, rather than sorting
This would be beneficial when there are few
Martijn van Oosterhout kleptog@svana.org writes:
What syntax were you envisioning? Does this value just need to be
passed to GiST at the creation of the the index, or does it actually
need to remembered by the backend and passed each call?
I should think that the index ought to remember any
On Tue, Sep 20, 2005 at 05:05:05PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Mon, Sep 19, 2005 at 10:16:36PM -0400, Bruce Momjian wrote:
Added to TODO:
* Allow DISTINCT to use hashing like GROUP BY
3 lines above we have...
Consider using hash buckets to do
Jim C. Nasby wrote:
What do these URL's have that the current TODO does not?
* Consider using hash buckets to do DISTINCT, rather than sorting
This would be beneficial when there are few distinct values. This is
already used by GROUP BY.
Maybe it's just me, but the recent
On Tue, Sep 20, 2005 at 06:45:07PM -0400, Bruce Momjian wrote:
Jim C. Nasby wrote:
What do these URL's have that the current TODO does not?
* Consider using hash buckets to do DISTINCT, rather than sorting
This would be beneficial when there are few distinct values. This is
Bruce Momjian wrote:
Andrew Dunstan wrote:
While preparing for a presentation, I noticed some mildly ugly effects
with log_line_prefix during session startup if log_connections is turned on.
Example (log_line_prefix = '%t [EMAIL PROTECTED] %r %p %c:%l'):
2005-09-19 19:16:39 EDT [EMAIL
On Tue, 20 Sep 2005, Martijn van Oosterhout wrote:
On Tue, Sep 20, 2005 at 11:26:26PM +0400, Oleg Bartunov wrote:
it's desirable to be able to pass parameters to CREATE INDEX for
GiST indices. Does SQL standard has something about that so we could
implement it for 8.2 ?
As has been pointed
pg_dump emits COMMENT ON DATABASE (if the database has a comment)
even when dumping only an individual schema or table. That seems
inappropriate, especially when copying data to a different cluster
where the named database might not exist or might have a different
comment that shouldn't be
On K, 2005-09-21 at 09:01 +0400, Oleg Bartunov wrote:
On Tue, 20 Sep 2005, Martijn van Oosterhout wrote:
What syntax were you envisioning? Does this value just need to be
passed to GiST at the creation of the the index, or does it actually
need to remembered by the backend and passed each
23 matches
Mail list logo
