Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> It evidently thinks that most of the rows in the join of part and
>>> partsupp won't have any matching rows in lineitem, whereas on average
>>> there are about 7 matching rows apiece. So that's totally wacko,
On Tue, Sep 26, 2006 at 08:51:10AM -0400, Tom Lane wrote:
> > 3. Do nothing. Let index scans mark the index tuple as dead when it's
> > convenient. There's no correctness problem with just leaving dead index
> > tuples there, because you have to check the index quals on each heap
> > tuple anywa
On Tue, Sep 26, 2006 at 05:27:56PM +0100, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> >Tom Lane wrote:
> >>Anything that involves having VACUUM re-evaluate index expressions is a
> >>nonstarter ... or have you already forgotten the optimizations we put
> >>into 8.2 that assume, eg, no s
On Tue, Sep 26, 2006 at 11:16:54AM +0100, Heikki Linnakangas wrote:
> To locate the actual matching items on the heap page, we have to scan
> the heap page because we don't have the item ids, so this is a tradeoff
> between CPU and I/O. However, we could have a hybrid where we initially
> store
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ISTM that we could gain additional insight on how many rows would likely
> result from a join be comparing the "shape" of the histogram for the
> joining columns.
eqjoinsel already does this for the case of comparing the MCV lists.
If you're serious abo
Since I don't recall any ideas ever having been thrown out on how to do
this...
ISTM that we could gain additional insight on how many rows would likely
result from a join be comparing the "shape" of the histogram for the
joining columns. For example, if the histogram arrays were exactly
identical
Josh Berkus writes:
>> What I'd like to do immediately is put in strlcpy() and hit the two or
>> three places I think are performance-relevant.
> Immediately? Presumably you mean for 8.3?
No, I mean now. This is a performance bug and it's still open season on
bugs. If we were close to having
Tom,
> What I'd like to do immediately is put in strlcpy() and hit the two or
> three places I think are performance-relevant. I agree with trying to
> get rid of StrNCpy/strncpy calls over the long run, but it's just code
> beautification and probably not appropriate for beta.
Immediately? Pre
Zdenek,
Hmmm ... we're not using the -fast option for the standard PostgreSQL
packages. Where did you start using it?
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will i
While looking around to see where to insert strlcpy(), I couldn't help
noticing that port/strdup.c has its very own header file,
include/strdup.h. AFAICS this is utterly redundant given that we have
#ifndef HAVE_STRDUP
extern char *strdup(char const *);
#endif
in port.h. Can anyone see a reason
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It evidently thinks that most of the rows in the join of part and
>> partsupp won't have any matching rows in lineitem, whereas on average
>> there are about 7 matching rows apiece. So that's totally wacko, and
>> it's not immed
luis garcia wrote:
> Hi I'm a student from Valencia-Venezuela and I'm working with some
> other friends to make PostgreSQL allows the definition of Temporal
> Databases and their respective Selection, Insertion and some other
> functions needed to treat this paradigm (all based in TSQL2 Query
> La
Hi I'm a student from Valencia-Venezuela and I'm working with some
other friends to make PostgreSQL allows the definition of Temporal
Databases and their respective Selection, Insertion and some other
functions needed to treat this paradigm (all based in TSQL2 Query
Language).
Right now we are
Neil Conway <[EMAIL PROTECTED]> writes:
> A wholesale replacement of strncpy() calls is probably worth doing --
> replacing them with strlcpy() if the source string is NUL-terminated,
> and I suppose memcpy() otherwise.
What I'd like to do immediately is put in strlcpy() and hit the two or
three p
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> You'll notice that it iterates once per char. Between that and the
> strlen() call in Tom's version, not sure which is the lesser evil.
Yeah, I was wondering that too. My code would require two scans of the
source string (one inside strlen and one in
On Tue, 2006-09-26 at 16:53 -0400, Tom Lane wrote:
> strlcpy does more than we need (note that none of the existing uses care
> about counting the overflowed bytes). Not sure if it's worth adopting
> those semantics when they're not really standard, but if you think a lot
> of people would be fami
Martijn van Oosterhout writes:
> I think that's why strlcpy was invented, to deal with the issues with
> strncpy.
> http://www.gratisoft.us/todd/papers/strlcpy.html
strlcpy does more than we need (note that none of the existing uses care
about counting the overflowed bytes). Not sure if it's wor
Martijn van Oosterhout wrote:
> On Tue, Sep 26, 2006 at 04:24:51PM -0400, Tom Lane wrote:
> > David Strong points out here
> > http://archives.postgresql.org/pgsql-hackers/2006-09/msg02071.php
> > that some popular implementations of strncpy(dst,src,n) are quite
> > inefficient when strlen(src) is
On Tue, Sep 26, 2006 at 04:24:51PM -0400, Tom Lane wrote:
> David Strong points out here
> http://archives.postgresql.org/pgsql-hackers/2006-09/msg02071.php
> that some popular implementations of strncpy(dst,src,n) are quite
> inefficient when strlen(src) is much less than n, because they don't
> o
David Strong points out here
http://archives.postgresql.org/pgsql-hackers/2006-09/msg02071.php
that some popular implementations of strncpy(dst,src,n) are quite
inefficient when strlen(src) is much less than n, because they don't
optimize the zero-pad step that is required by the standard.
It look
Hi, Marlon,
Marlon Petry wrote:
> would like to know postgres implements ACID ?
>
> has some document ?
http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html
HTH,
Schabi
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fi
On Tue, Sep 26, 2006 at 02:18:59PM -0400, Tom Lane wrote:
> at the error string is of course not localization-proof, so we'd have to
> break down that errcode into some more-specific categories. Which is
> probably not a bad idea anyway, but it would mean that the nicer
> behavior would only happe
Hello list
would like to know postgres implements ACID ?
has some document ?
thanks
Ühel kenal päeval, E, 2006-09-25 kell 14:03, kirjutas Josh Berkus:
> All,
>
> Here:
> http://pgfoundry.org/docman/view.php/147/233/release82.zip
> is a zip file of a draft of the PostgreSQL 8.2 release and accompanying
> press kit. Please check if the technical details are correct, and get
On Tue, Sep 26, 2006 at 11:58:27AM -0400, Tom Lane wrote:
> If psql wants a Password:, it won't gracefully give up in response to
> ^C, ^D, or ^J ... you *must* enter a nonempty string before you can get
> your console back. This is pretty unfriendly, and I don't recall prior
> versions behaving t
As per a recent discussion in pgsql-admin,
http://archives.postgresql.org/pgsql-admin/2006-09/msg00297.php
libpq doesn't cope well with the situation where the server is
configured to allow only SSL connections (or only non-SSL connections)
and there is some unrelated-to-SSL connection problem such
I have run into the issue with our linux boxes connecting with the JDBC
driver. Lucky for us our connections already go over encrypted VPN
connections so I could get by with the following in my pg_hba.conf
hostssl all all 192.168.176.0 255.255.255.0 md5
hostall all 192
Thank you, Thank you, Thank you!! :o)
Jeff - Thanks in particular for your help on this, it is greatly
appreciated!
It was a hidden folder, but not anymore!! I found the file and re-set the
password for the 'postgres' user and can now connect using my 'md5' hostssl
connection:
hostssl
On Tue, 26 Sep 2006, Alvaro Herrera wrote:
Jeanna Geier wrote:
Searched again for 'pgpass' and for the 'Application Data' directory with
no luck...
The file is called "pgpass.conf" on Windows. As for the "Application
Data", it may be called differently if your Windows is localized -- try
loo
Jeanna Geier wrote:
> Searched again for 'pgpass' and for the 'Application Data' directory with
> no luck...
The file is called "pgpass.conf" on Windows. As for the "Application
Data", it may be called differently if your Windows is localized -- try
looking for %APPDATA%. (I think I'd do this b
Searched again for 'pgpass' and for the 'Application Data' directory with no
luck...
And, tell me it ain't so "you don't have to build the windows version from
source to use SSL" -- I had two seperate posters tell me that I did and I
wrestled with it for a bit...for nothing?? Ah, live and lea
Tom,
On 9/26/06 9:15 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> ! | @ 6 years | @ 5 years 12 mons 5 days 6 hours
>
>> Doesn't this look odd regardless of what bad results come back from the
>> FP library?
>
> It looks exact
On Tue, 26 Sep 2006, Jeanna Geier wrote:
Any thoughts?? Like I said previously, I did build this on Windows from
source so we could use the SSL option.could I have missed something when
I was doing that? (It was my first time and I was following instructions from
the INSTALL docs)
Jean
OK, so after doing some more testing and configuring to see if I can narrow
this down, I'm more confused than ever! =) Because now I cannot connect to
my database unless the method is 'trust'; shouldn't I be able to connect
using the correct password if 'password' is the method in the pg_hba.co
Zdenek,
Zdenek Kotala <[EMAIL PROTECTED]> writes:
But the question is if the "-fast" flag is good for postgres. The
-fast flag sets "brutal" floating point optimization and some
operation should have less precision. Is possible verify that
floating point operation works well?
That's a prett
On Tue, 26 Sep 2006, Jeff Frost wrote:
But, when I put the trust line back with hostssl, I do not get connected as
per her original indication. Of course this is with my 8.1.4 windows server
and not 8.0.8. Is it possible that 8.0.8 was more liberal with the hostssl
vs host interpretation if
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Also, now that we have concurrent CREATE INDEX, we could implement
> concurrent REINDEX as well, I believe.
That's probably more easily said than done --- in particular, I don't
understand what the committed state after the first transaction would
On Tue, 26 Sep 2006, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Interestingly, I receive the same error when I disable SSL on the server:
If SSL is disabled then hostssl lines in pg_hba.conf effectively become
no-ops --- they can never be matched since no incoming connection will
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>>> Anything that involves having VACUUM re-evaluate index expressions is a
>>> nonstarter ... or have you already forgotten the optimizations we put
>>> into 8.2 that assume, eg, no sub-transactions withi
Jeff Frost <[EMAIL PROTECTED]> writes:
> Interestingly, I receive the same error when I disable SSL on the server:
If SSL is disabled then hostssl lines in pg_hba.conf effectively become
no-ops --- they can never be matched since no incoming connection will
be SSL-ified. So that part of it sounds
Heikki Linnakangas wrote:
Tom Lane wrote:
Anything that involves having VACUUM re-evaluate index expressions is a
nonstarter ... or have you already forgotten the optimizations we put
into 8.2 that assume, eg, no sub-transactions within a VACUUM?
Umm, I'm afraid I have. Could you give me a clu
Heikki Linnakangas wrote:
> Tom Lane wrote:
> >Anything that involves having VACUUM re-evaluate index expressions is a
> >nonstarter ... or have you already forgotten the optimizations we put
> >into 8.2 that assume, eg, no sub-transactions within a VACUUM?
>
> Umm, I'm afraid I have. Could you gi
Simon Riggs <[EMAIL PROTECTED]> writes:
> Recommending downgrade of these annoying messages from LOG to DEBUG1:
> 2006-09-23 15:57:56 EDT_3147 LOG: transaction ID wrap limit is 2147484170,
> limited by database "postgres"
Seems reasonable --- we put that in at LOG level for purposes of testing
"Strong, David" <[EMAIL PROTECTED]> writes:
> The specification for strncpy () indicates that when the length of the
> source string (4 bytes) is less than the length of the number of bytes
> to copy (2500 bytes), the remainder of the destination string will be
> padded with NULL bytes (2496). Base
Hello guys,
I would like to ask you to change my name on picture from "Radovan
Jablonov" to "Radovan Jablonovsky". I am guy bellow Postgresql sign
sitting on the ground in dark red shirt.
Sincerely,
Radovan Jablonovsky
Database Architect/DBA
Arrow Tran
On Tue, 26 Sep 2006, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Do you remember if the problem was on the 8.0.8 server side that caused the
lack of prompting?
No, I'm pretty sure it was a client-side issue (and I thought we'd fixed
it by 8.0.8 anyway, so I'm glad to see your test
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ! | @ 6 years | @ 5 years 12 mons 5 days 6 hours
> Doesn't this look odd regardless of what bad results come back from the
> FP library?
It looks exactly like the sort of platform-dependent rounding issue that
Bruce and Michae
Tom Lane wrote:
Anything that involves having VACUUM re-evaluate index expressions is a
nonstarter ... or have you already forgotten the optimizations we put
into 8.2 that assume, eg, no sub-transactions within a VACUUM?
Umm, I'm afraid I have. Could you give me a clue?
3. Do nothing. Let ind
Jeff Frost <[EMAIL PROTECTED]> writes:
> Do you remember if the problem was on the 8.0.8 server side that caused the
> lack of prompting?
No, I'm pretty sure it was a client-side issue (and I thought we'd fixed
it by 8.0.8 anyway, so I'm glad to see your test agrees).
Jeanna, do you maybe have a
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
I tried regression test with Postgres Beta and horology test field. See
attached log. It appears few month ago - see
http://archives.postgresql.org/pgsql-ports/2006-06/msg4.php
I used Sun Studio 11 with -fast flag and SPARC platform.
Are you
On Tue, 26 Sep 2006, Jeff Frost wrote:
As for Jeanna's problem, I don't see any password prompt at all in her
example. I've forgotten the details, but wasn't there a password
prompting problem with 8.0.x on Windows?
It worked great with 8.1.4. Let me download 8.0.8 and try that on Windows
I suspect the '-fast' introduced arithmetic associativity transformations that
horology is sensitive to. I've seen this in the past.
The solution I used was to mod the Makefile to exclude the sensitive routines
from the aggressive optimizations. As I recall, adt.c was the prime culprit.
- Luk
We're looking for some advice and/or comments.
During performance and scalability testing with 8.1.4 and also 8.2Beta1,
OProfile reported that the strncpy () C library call was taking a large
amount of CPU time while we were running one of our benchmarks.
We traced a partial benchmark run using l
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
But the question is if the "-fast" flag is good for postgres. The -fast
flag sets "brutal" floating point optimization and some operation should
have less precision. Is possible verify that floating point operation
works well?
Tha
If psql wants a Password:, it won't gracefully give up in response to
^C, ^D, or ^J ... you *must* enter a nonempty string before you can get
your console back. This is pretty unfriendly, and I don't recall prior
versions behaving that way (though I so seldom use a password with PG
that I might be
On Tue, 26 Sep 2006, Tom Lane wrote:
"Jeanna Geier" <[EMAIL PROTECTED]> writes:
[ hostssl works with 'trust' but not 'md5' ]
It's only when I change the connection method to 'md5' that I'm running into
problems -- then I cannot connect from pgadmin or the command line.
As for Jeanna's proble
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
But the question is if the "-fast" flag is good for postgres. The -fast
flag sets "brutal" floating point optimization and some operation should
have less precision. Is possible verify that floating point operation
works well?
"Jeanna Geier" <[EMAIL PROTECTED]> writes:
> [ hostssl works with 'trust' but not 'md5' ]
> It's only when I change the connection method to 'md5' that I'm running into
> problems -- then I cannot connect from pgadmin or the command line.
I experimented with this using CVS HEAD, and found that SS
Hi, Bruce,
Bruce Momjian wrote:
>>> Allow inheritance to be removed from tables
>> I'd enhance that to "Allow table inheritance relationships to be defined
>> for and removed from pre-existing tables."
>
> Good point. Updated wording:
>
> Allow table inheritance to be added and
Teodor Sigaev wrote:
> > Right now, if an index entry points to a dead tuple, we set a bit in
> > the index so future lookups do not access the heap. We could set a bit
> > for block index entries that point to a page that has no live rows, and
> > have vacuum remove the index entry later.
>
>
Markus Schaber wrote:
-- Start of PGP signed section.
> Hi, Bruce,
>
> Bruce Momjian wrote:
>
> >
> >
> > Allow inheritance to be removed from tables
> >
> >
>
> I'd enhance that to "Allow table inheritance relationships to be defined
> for and removed from
On Tue, Sep 26, 2006 at 12:35:54PM +0100, Heikki Linnakangas wrote:
> Tom Lane wrote:
> >>We could rename pg_attribute as pg_userattribute, and remove all the
> >>system attributes from that. To stay backwards-compatible, we could have
> >>a pg_attribute view on top of that contained the system a
On Tue, 26 Sep 2006, Heikki Linnakangas wrote:
> Looks a bit better now, though I think you need to think more about the
> encapsulation of the structs. More detailed comments below.
>
> Jie Zhang wrote:
> > Essentially, we want to have a stream bitmap object that has an iterator,
> > which will b
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> What's the purpose of mark/restrpos in heapam.c?
It's deadwood --- see the comment for ExecSupportsMarkRestore:
/*
* ExecSupportsMarkRestore - does a plan type support mark/restore?
*
* XXX Ideally, all plan node types would support mark/restore
On Mon, 2006-09-25 at 14:03 -0700, Josh Berkus wrote:
> Here:
> http://pgfoundry.org/docman/view.php/147/233/release82.zip
> is a zip file of a draft of the PostgreSQL 8.2 release and accompanying
> press kit. Please check if the technical details are correct, and get
> back to me with any
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
I've been experimenting with the idea of a so-called Block B-Tree. The
basic idea is that instead of storing an index tuple for each heap
tuple, we store an index tuple for each heap block. This dramatically
reduces the size of
Right now, if an index entry points to a dead tuple, we set a bit in
the index so future lookups do not access the heap. We could set a bit
for block index entries that point to a page that has no live rows, and
have vacuum remove the index entry later.
GIN don't support this feature...
--
Te
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If we're going to fool with these, I'd like to renew the suggestion I
>> made awhile back that none of the system columns should have explicit
>> entries in pg_attribute, but rather their lookup should be special-cased
>> in the pa
Casey Duncan wrote:
> Seems like the unit used for shared_buffers (and others) should be
> megabytes then with a minimum of 1 (or more). Is less than 1MB
> granularity really useful here?
Yes, there are platforms that allow as little as 512 kB of shared memory
by default.
--
Peter Eisentraut
ht
Hi, Bruce,
Bruce Momjian wrote:
>
>
> Allow inheritance to be removed from tables
>
>
I'd enhance that to "Allow table inheritance relationships to be defined
for and removed from pre-existing tables."
HTH,
Markus
--
Markus Schaber | Logical Tracking&Trac
Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >
> >> I've been experimenting with the idea of a so-called Block B-Tree. The
> >> basic idea is that instead of storing an index tuple for each heap
> >> tuple, we store an index tuple for each he
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries in pg_attribu
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > I created a major features list for 8.2 and put it into CVS. Instead of
> > going into detail (meaning the item would not appear in the "Changes"
> > section below, I just highlighted some of the big stuff, and was
> > purposely vague about the deta
> And we're back to routine REINDEX I guess :-(. This doesn't seem like a
> satisfactory answer.
If the reindex works online, it could be a satisfactory solution.
Cheers,
Csaba.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I've been experimenting with the idea of a so-called Block B-Tree. The
> basic idea is that instead of storing an index tuple for each heap
> tuple, we store an index tuple for each heap block. This dramatically
> reduces the size of an index, lea
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> VACUUM?
>>
> There's a few options that I've thought of this far:
> 1. Whenever a tuple is found dead on page X, vacuum of the index will
> have to go to that page again to see if there's any matching tuples left.
Anything that
Teodor Sigaev wrote:
Right now, if an index entry points to a dead tuple, we set a bit in
the index so future lookups do not access the heap. We could set a
bit for block index entries that point to a page that has no live
rows, and
have vacuum remove the index entry later.
GIN don't suppor
On Mon, Sep 25, 2006 at 02:23:39PM +0100, Dave Page wrote:
> testing connect/test1.pgc ... FAILED (log)
> testing compat_informix/dec_test.pgc ... FAILED (output)
> testing preproc/variable.pgc ... FAILED (log, output)
> testing pgtypeslib/dt_test.pg
Zdenek Kotala wrote:
> I tried regression test with Postgres Beta and horology test field. See
> attached log. It appears few month ago - see
> http://archives.postgresql.org/pgsql-ports/2006-06/msg4.php
> I used Sun Studio 11 with -fast flag and SPARC platform.
Are you looking for ways to c
I've been experimenting with the idea of a so-called Block B-Tree. The
basic idea is that instead of storing an index tuple for each heap
tuple, we store an index tuple for each heap block. This dramatically
reduces the size of an index, leading to savings on I/O. This idea was
briefly discusse
What's the purpose of mark/restrpos in heapam.c?
AFAIK, mark/restore is only used by merge joins, and you can't feed a
merge join from a heap scan because merge join requires sorted input.
Unless I'm missing something, heap_markpos and heap_restrpos are dead code.
--
Heikki Linnakangas
Ente
Tom Lane wrote:
We could rename pg_attribute as pg_userattribute, and remove all the
system attributes from that. To stay backwards-compatible, we could have
a pg_attribute view on top of that contained the system attributes as well.
I don't really think this is necessary. How many clien
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Page
> Sent: 26 September 2006 10:41
> To: Michael Meskes
> Cc: Joachim Wieland; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Buildfarm alarms
>
>
>
> > -Original Message-
>
> -Original Message-
> From: Michael Meskes [mailto:[EMAIL PROTECTED]
> Sent: 26 September 2006 10:39
> To: Dave Page
> Cc: Joachim Wieland; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Buildfarm alarms
>
> On Tue, Sep 26, 2006 at 09:57:16AM +0100, Dave Page wrote:
> > OK, I n
Looks a bit better now, though I think you need to think more about the
encapsulation of the structs. More detailed comments below.
Jie Zhang wrote:
Essentially, we want to have a stream bitmap object that has an iterator,
which will be able to iterate through the bitmaps. The BitmapIndexscan,
On Sun, 24 Sep 2006, Jeremy Drake wrote:
> On Thu, 21 Sep 2006, Tom Lane wrote:
>
> > I think we could do without the Moby Dick extract too ...
>
> I am open to suggestions. I saw one suggestion that I use an image of an
> elephant, but I suspect that was tongue-in-cheek. I am not very fond of
>
> -Original Message-
> From: Michael Meskes [mailto:[EMAIL PROTECTED]
> Sent: 26 September 2006 08:57
> To: Joachim Wieland
> Cc: Dave Page; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Buildfarm alarms
>
> On Mon, Sep 25, 2006 at 09:20:19PM +0200, Joachim Wieland wrote:
> > Michael, cou
On Tue, Sep 26, 2006 at 09:57:16AM +0100, Dave Page wrote:
> OK, I now see just one, date format related failure:
> ...
Did you run it with Joachim's patch or with up-to-date CVS checkout? It
seems to me that you do not have the latest changes to CVS. We added a
"set datestyle" to variable.pgc tha
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> But the question is if the "-fast" flag is good for postgres. The -fast
> flag sets "brutal" floating point optimization and some operation should
> have less precision. Is possible verify that floating point operation
> works well?
That's a pretty go
I tried regression test with Postgres Beta and horology test field. See
attached log. It appears few month ago - see
http://archives.postgresql.org/pgsql-ports/2006-06/msg4.php
I used Sun Studio 11 with -fast flag and SPARC platform.
I played little bit with cc flags and following flags wo
90 matches
Mail list logo
