Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.
No :)
On Wed, Mar 09, 2005 at 03:43:38PM +0800, Christopher Kings-Lynne wrote:
Hrm, I just did a gmake install; gmake installcheck - that worked fine.
Then I did gmake check again and now that works fine...
It must have been picking up something from my previously installed pgsql.
Do you have a
On Mon, Mar 07, 2005 at 11:53:59PM +, Simon Riggs wrote:
On Mon, 2005-03-07 at 09:39 -0500, Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
[skipped]
Well, we're using the CRC in 3 separate places...
(1) for xlog records
(2) for complete blocks copied to xlog
(3) for
On Tue, 2005-03-08 at 15:30 +0200, Ioannis Theoharis wrote:
let me, i have turned enable_seqscan to off, in order to discourage
optimizer to choose seq_scan whenever an idex_scan can be used.
But in this case, why optimizer don't chooses seq_scan (discourage is
different than prevent) ?
On Wed, 2005-03-09 at 11:02 +1100, Neil Conway wrote:
Oleg Bartunov wrote:
I just noticed a little optimizer problem - in second query there is
unused 'tycho t2' table alias which gets backend buried.
It's not an unused table alias, it is specifying the cartesian product
of `tycho' with
Simon Riggs wrote:
Oleg is saying that the optimizer doesn't protect against foolish SQL
requests. His query is an example of a foolishly written query.
IMHO calling this a foolishly written query is completely arbitrary. I
can imagine plenty of applications for which a cartesian join makes
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
On Wed, 2005-03-09 at 22:38 +1100, Neil Conway wrote:
Simon Riggs wrote:
Oleg is saying
On Wed, 9 Mar 2005, Simon Riggs wrote:
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
I have no problem with that ! I just wanted to take a
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa and a half
a dozen
Michael Fuhr [EMAIL PROTECTED] writes:
Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's
Do you have a way to revert to the old installation to check whether
the checks fail again? It might be useful to track down exactly
what happened. It seems wrong that a currently-installed version
should have adverse effects on a just-built version's regression
tests.
We've seen that happen
From what I recall from the conversation, I would say rename the vsprintf
and the sprintf functions in postgres to pq_vsnprintf and pq_snprintf.
Define a couple macros: (in some common header, pqprintf.h?)
#define snprintf pq_snprintf
#define vsnprintf pq_snprintf
Then just maintain the postgres
Neil Conway [EMAIL PROTECTED] writes:
In any case, when this problem does occur, it is obvious to the user that
something is wrong, and no harm is done.
I don't see why you say that. The whole complaint here is that it's *not*
obvious something is wrong and there *is* damage until it's
Ühel kenal päeval (teisipäev, 8. märts 2005, 00:52+0100), kirjutas
Gaetano Mendola:
Hi all,
running a 7.4.5 it happen to me with another table
where a single vacuum full was not freeing enough pages,
here the verbose vacuum full, as you can see only at
the end: truncated 8504 to 621 pages.
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I configured my web application to use it, so I could
Oleg Bartunov wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and pg801:5433
as second one. Pgpool is running on default port () and
I configured my web application to
On Wed, 9 Mar 2005, Jeff Hoffmann wrote:
Oleg Bartunov wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and pg801:5433 as
second one. Pgpool is running on default port ()
Simon, Neil, all:
IMHO calling this a foolishly written query is completely arbitrary. I
can imagine plenty of applications for which a cartesian join makes
sense. In this case the user didn't write the query they meant to write
-- but it is surely hopeless to prevent that in the general case
Oleg Bartunov wrote:
On Wed, 9 Mar 2005, Jeff Hoffmann wrote:
Oleg Bartunov wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running
Scenario:
A user download a pre-built PostgreSQL 7.4.7 from somewhere and a
pre-built pljava distro from gborg. He gets everything running but
suddenly encounteres problems with the timetz type. PL/Java apparently
return the time as zero. The problem is caused by the postgresql binary
being
Thomas Hallgren [EMAIL PROTECTED] writes:
A user download a pre-built PostgreSQL 7.4.7 from somewhere and a
pre-built pljava distro from gborg. He gets everything running but
suddenly encounteres problems with the timetz type. PL/Java apparently
return the time as zero. The problem is
Tom Lane wrote:
Why is PL/Java dependent on the internal representation of any
particular datatype? Seems like this is a symptom of bad PL design
more than anything else.
I didn't see any other way of doing it short of using string
conversions. That doesn't seem very optimal. Java's internal
I wrote:
I think the problem can be expressed as
regression=# select 2 as id, max(b) from t2 having 2 = 1;
id | max
+-
2 |
(1 row)
the issue is clearly that the known-false HAVING clause is pushed down
inside the aggregation, as though it were WHERE. The existing code
Neil Conway wrote:
Simon Riggs wrote:
Oleg is saying that the optimizer doesn't protect against foolish SQL
requests. His query is an example of a foolishly written query.
IMHO calling this a foolishly written query is completely arbitrary. I
can imagine plenty of applications for which a
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I configured my web application to use it, so I
I encounter the similar problem in make check (win2k-mingw, 8.0.1). The
regression test could randomly fail due to could not write block (Invalid
argument) problem or could not remove file problem.
Regards,
Qingqing
p.s. I believe this could be a potential serious problem, so I forward it to
I wrote in reference to bug#1528:
What the spec actually says, or at least implies, is that a HAVING
clause is to be evaluated only once per group --- where the group
is the whole table if there's no GROUP BY clause.
In fact, reading the spec more closely, it is clear that the presence
of
On Mar 9, 2005, at 7:25 PM, Tatsuo Ishii wrote:
That's an intended behavior. Or at least a side effect of failover
design. If we allow unlimited switching between the master and the
secondary, pgpool could repeat switching forever if we have unliable
network or hardware.
I didn't really think of
Tom Lane wrote:
What that means is that neither the HAVING clause nor the targetlist
can use any ungrouped columns except within aggregate calls; that is,
select col from tab having 21
is in fact illegal per SQL spec, because col isn't a grouping column
(there are no grouping
Tom Lane [EMAIL PROTECTED] writes:
In particular this whole business of moving HAVING into WHERE is
wrong and should go away.
It sort of seems like select aggregate(col) from tab with no GROUP BY clause
is a bit of a special case. The consistent thing to do would be to return no
records. It's
Nicolai Tufar wrote:
Dear all,
After struggling for one week to to integrate FreeBSD's vfprintf.c into
PostgreSQL I finally gave up. It is too dependent on underlying
FreeBSD system functions. To incorporate it into PostgreSQL we need
to move vfprintf.c file itself, two dozen files form gdtoa
Kevin Brown [EMAIL PROTECTED] writes:
Hence, it makes sense to go ahead and run the query, but issue a
warning at the very beginning, e.g. WARNING: query JOINs tables list
of tables without otherwise referencing or making use of those
tables. This may cause excessively poor performance of
Comments? Can anyone confirm whether DB2 or other databases allow
ungrouped column references with HAVING?
Oracle does not allow such references. It issues ORA-00979: not a
GROUP BY expression when you try to hand it such a reference.
MS SQL Server does not allow such references either, yielding
The current _pg_keypositions function generates the numbers from 1 to 32
using a massive union, shouldn't it just use generate_series instead (to
make it faster/simpler)?
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free
On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I configured my
On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I
On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
However it would be easy to modify pgpool to allow automatic switch
back (with a risk of unwanted repeating switching, of course). Is
this what you want?
No, your arguments are important. I don't want too much intelligence, but
when I restart primary
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Comments? Can anyone confirm whether DB2 or other databases allow
ungrouped column references with HAVING?
MySQL allows it:
A slightly tighter experiment shows that they treat HAVING like WHERE
in this case:
mysql create table tab(col int);
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
The current _pg_keypositions function generates the numbers from 1 to 32
using a massive union,
Only for very small values of current ...
regards, tom lane
---(end of
Greg Stark [EMAIL PROTECTED] writes:
It sort of seems like select aggregate(col) from tab with no GROUP BY clause
is a bit of a special case. The consistent thing to do would be to return no
records.
I don't think so. SQL99 defines this stuff in a way that might make you
feel better: it says
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Wednesday, March 09, 2005 8:45 PM
To: Christopher Kings-Lynne
Cc: Kevin Brown; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] We are not following the spec for HAVING without
GROUP
Only for very small values of current ...
Argh! Forgot it was a 7.4 server :) Oops.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Are we able to run more NIST tests now?
http://www.itl.nist.gov/div897/ctg/sql_form.htm
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Are we able to run more NIST tests now?
http://www.itl.nist.gov/div897/ctg/sql_form.htm
I thought we'd extracted all the interesting juice from the NIST tests
a couple years ago. Specifically I recall this fix came out of NIST
testing done by
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I thought we'd extracted all the interesting juice from the NIST tests
a couple years ago.
I was just chatting with Neil C on IRC and he mentioned that back when
they were using it at RedHat, PostgreSQL didn't have schemas so most
stuff
I thought we'd extracted all the interesting juice from the NIST tests
a couple years ago. Specifically I recall this fix came out of NIST
testing done by Red Hat:
2003-06-06 11:04 tgl
Implement outer-level
aggregates to conform to the SQL spec, with extensions to support
46 matches
Mail list logo
