Hello List,
I have already posted an e-mail on the general mailing list but on the
advice of Devrim Gunduz ;-) , I try on this mailing list.
I try to generate the RPM from the src.rpm downloaded on the
postgresql.org web site. I work on an IA-64 server with Red Hat
Enterprise Linux 4 AS
One thing I do worry about is if both postgresql and the OS
are both delaying write()s in the hopes of collapsing them
at the same time. If so, this would cause both to be experience
bigger delays than expected, and make checkpoints worse.
That is my concern. Letting 30 seconds
Ron Mayer wrote:
Jim C. Nasby wrote:
On usage, ISTM it would be better to turn on GIT only for a clustered
index and not the PK? I'm guessing your automatic case is intended for
SERIAL PKs, but maybe it would be better to just make that explicit.
Not necessarily; since often (in my tables at
Hi Tom,
Thanks for your help,
I will try it ASAP and report maybe tonighgt CET.
Also, Makefile.port needs a little patch that I'll send to.
On Mon, 11 Dec 2006, Tom Lane wrote:
Date: Mon, 11 Dec 2006 11:26:14 -0500
From: Tom Lane [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc:
Hi!
I think this was caused by a description mistake of postgresql-test.patch.
'/SLONY_PGS/PostgreSQL_8.2.0/BUILD/postgresql-8.2.0/src/test/regres/../../../contrib/spi/refint.so
LANGUAGE C;
CREATE FUNCTION check_foreign_key ()
RETURNS trigger
! AS
Hi,
On Tue, 2006-12-12 at 19:57 +0900, Tatsuhito Kasahara wrote:
I think this was caused by a description mistake of
postgresql-test.patch.
Yeah, I just figured that while I was looking at what Tom did for FC-7
RPMs.
I committed the new patch to CVS.
Regards,
--
The PostgreSQL Company -
Thank you very much : it works
-bash-3.00$ gmake check 21 |tee traces_check8.2.0_gcc_121206_v2.log
... ... ...
test create_function_1... ok
triggers ... ok
... ... ...
===
All 103 tests passed.
===
The problems were those you found :
-
On Tue, Dec 12, 2006 at 3:22 AM, in message
[EMAIL PROTECTED],
Zeugswetter
Andreas ADI SD [EMAIL PROTECTED] wrote:
One thing I do worry about is if both postgresql and the OS
are both delaying write()s in the hopes of collapsing them
at the same time. If so, this would cause both to be
Is this a bug, or don't I understand coalesce()?
create table test (a int, b int);
insert into test values (1,null);
insert into test values (2,1);
insert into test values (2,2);
select * from test; -- returns:
select sum(b) from test where a=1; -- null
Patrick Welche wrote:
Is this a bug, or don't I understand coalesce()?
create table test (a int, b int);
insert into test values (1,null);
insert into test values (2,1);
insert into test values (2,2);
select * from test; -- returns:
select sum(b) from test where a=1;
Patrick Welche [EMAIL PROTECTED] writes:
Is this a bug, or don't I understand coalesce()?
select coalesce(0,sum(b)) from test where a=2; -- 0 !
So when I use coalesce() with sum(), I always get the constant. I would
have expected it only in the case where sum() returns null..
Coalesce
COALESCE returns the leftmost non-null value. Perhaps what you wanted
was sum(coalesce(b,0)) instead of coalesce(0,sum(b))
On Tue, Dec 12, 2006 at 9:22 AM, in message
[EMAIL PROTECTED], Patrick Welche
[EMAIL PROTECTED] wrote:
Is this a bug, or don't I understand coalesce()?
create table
Olivier PRENANT wrote:
When I swithed to the newest version og pgbuildfarm, I noticed that
--with-ldap (now by defaut) didn't work on UnixWare.
This is because, on Unixware, ldap needs lber and resolv.
Is libldap a static library on that system?
Or do shared libraries on Unixware
All,
You may or may not be aware that Dan Langille of FreeBSD (and BSDCan) is
running a PostgreSQL conference in Ottawa this May:
http://www.pgcon.org/2007/
In one week, PGCon will start accepting paper and tutorial submissions.
Dan needs a committee ... ideally 4-6 people ... from the
Albe Laurenz [EMAIL PROTECTED] writes:
Shouldn't that be
AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
[AC_MSG_ERROR([library 'ldap_r' is required for
LDAP])],
[$PTHREAD_LIBS $EXTRA_LDAP_LIBS])
Ooops, of course. Like I said, untested ;-)
On Tue, Dec 12, 2006 at 03:33:04PM +, Heikki Linnakangas wrote:
BTW: This type of questions really belong to pgsql-general or
pgsql-novice, this list is for discussing development of PostgreSQL itself.
^^
Indeed - I am truly feeling like a novice now...
Cheers,
Patrick
I have thought a while about this and I have some ideas.
Ideally, we would be able to trickle the sync of individuals blocks
during the checkpoint, but we can't because we rely on the kernel to
sync all dirty blocks that haven't made it to disk using fsync(). We
could trickle the fsync() calls,
Tom Lane wrote:
I like Kevin's settings better than what Jim suggests. If the bgwriter
only makes one sweep between checkpoints then it's hardly going to make
any impact at all on the number of dirty buffers the checkpoint will
have to write. The point of the bgwriter is to reduce the
Gregory Stark [EMAIL PROTECTED] writes:
It's a fundamental shift in the idea of the purpose of bgwriter. Instead of
trying to suck i/o away from the subsequent checkpoint it would be responsible
for all the i/o of the previous checkpoint which would still be in progress
for the entire time of
On Tue, Dec 12, 2006 at 04:42:50PM +0100, Albe Laurenz wrote:
Or do shared libraries on Unixware generally 'not remember'
the libraries they were linked against (this would be strange).
It could be that whoever compiled libldap there did not include the
dependancies at link time. It is legal to
Heikki Linnakangas wrote:
Jim C. Nasby wrote:
On Thu, Dec 07, 2006 at 10:30:11AM +, Heikki Linnakangas wrote:
I've cut a new version of the GIT patch I posted earlier, and collected
all my dispersed todo-lists, post-it notes, performance results,
supplementary patches etc. I had to a
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql conn:service=sname user=uname
Instead of providing yet another switch, I overloaded the dbname
parameter so that if it has the recognised prefix the
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql conn:service=sname user=uname
Perhaps this should be implemented in libpq, not at the psql level?
Otherwise you're
Richard Huxton wrote:
Simon Riggs wrote:
Intermediate results are always better than none at all. I do understand
what a partial execution would look like - frequently it is the
preparatory stages that slow a query down - costly sorts, underestimated
hash joins etc. Other times it is loop
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I have been working on providing psql with the ability to accept a libpq
conninfo string, so that the following now works for me:
psql conn:service=sname user=uname
Perhaps this should be implemented in libpq, not at the psql
On Tue, Dec 12, 2006 at 05:44:07PM -0500, Andrew Dunstan wrote:
Now I look at fe-connect.c more closely, I'm tempted just to try parsing
the dbname param as a conninfo string, and if it doesn't work fall back
on a plain dbname. I could greatly reduce the chance of following the
failure path
I noticed today that process_implied_equality() still contains an ugly
hack that should have been got rid of awhile ago: it assumes that
mergejoinable operators are named =. This has been a bogus assumption
for several releases, as illustrated by this failure:
regression=# select * from text_tbl
Martijn van Oosterhout kleptog@svana.org writes:
Does that mean that:
psql -d service=myservice
should Just Work(tm)? That would be nice.
Even more to the point,
psql service=myservice
which is why we want to overload dbname rather than any of the other
PQsetdbLogin parameters for
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Does that mean that:
psql -d service=myservice
should Just Work(tm)? That would be nice.
Even more to the point,
psql service=myservice
which is why we want to overload dbname rather than any of the other
I am trying to create the libpq.a as a universal binary (both ppc and
intel macs). Does anyone have any information on this process?
Thanks,
Ted
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there was
anything wrong with your syntax (eg, misspelled
On Dec 13, 2006, at 7:56 , Tom Lane wrote:
Right offhand I cannot see a reason why there should be different
equality operators with the same sortops. (If anyone can come up with
a plausible scenario for that, stop me here...) So what I'm thinking
about is a unique index on
Michael Glaesemann [EMAIL PROTECTED] writes:
On Dec 13, 2006, at 7:56 , Tom Lane wrote:
Right offhand I cannot see a reason why there should be different
equality operators with the same sortops. (If anyone can come up with
a plausible scenario for that, stop me here...)
I think this makes
I mentioned this a while back, now that 8.2 is out perhaps others will be more
interested in new code.
Currently Postgres regression tests only test functionality within a single
session. There are no regression tests that test the transaction semantics or
locking behaviour across multiple
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a conninfo string and there
I wrote:
Right offhand I cannot see a reason why there should be different
equality operators with the same sortops. (If anyone can come up with
a plausible scenario for that, stop me here...)
BTW, I think it's possible to prove that there need never be two for the
case of both sides the same
On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote:
* Have EXPLAIN ANALYZE highlight poor optimizer estimates
TODO updated:
* Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
actual row counts differ by a specified percentage
I don't think this is
Casey Duncan wrote:
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get a fairly
unhelpful message if you intended a
On Dec 12, 2006, at 5:16 PM, Andrew Dunstan wrote:
Casey Duncan wrote:
On Dec 12, 2006, at 3:37 PM, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Right. Here's the patch I just knocked up, which seems to Just
Work (tm) ;-)
The main objection I can see to this is that you'd get
Casey Duncan wrote:
I was speaking from and end-user point of view, but I see your point.
It's certainly attractive to just patch libpq and be done. However,
that does have the side-effect of implicitly propagating the behavior
to all libpg client software. That may be more unpleasantly
I just noticed that defining LOCK_DEBUG causes a compile failure (have
not delved into how to fix, but thought it would be worth noting at this
point!):
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -I.
On Dec 13, 2006, at 8:45 , Tom Lane wrote:
the entire operator/function structure is built on the
assumption that there is, say, only one = between any two datatypes.
You mean only on = between any two values of a given datatype? Or
is there something else I'm missing? So what you're doing
Andrew Dunstan [EMAIL PROTECTED] writes:
We change libpq from time to time. Besides, how many DBs are there that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I don't
expect lots of surprise.
Um, but how many DB names have an = in them at all?
Basically what this proposal is
On Dec 13, 2006, at 12:33 , Michael Glaesemann wrote:
On Dec 13, 2006, at 8:45 , Tom Lane wrote:
the entire operator/function structure is built on the
assumption that there is, say, only one = between any two
datatypes.
You mean only on = between any two values of a given datatype?
Neil Conway wrote:
On Tue, 2006-12-12 at 17:30 -0500, Bruce Momjian wrote:
* Have EXPLAIN ANALYZE highlight poor optimizer estimates
TODO updated:
* Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and
actual row counts differ by a specified percentage
As usual, following item in the 8.1.5 release note is pretty vague:
* Efficiency improvements in hash tables and bitmap index scans(Tom)
Especially I'm wondering what was actually improved in bitmap index
scans. I see several commit messages regarding bitmap index scans, but
I cannot figure
While testing a PITR recovery, I discovered that recovery.conf doesn't
seem to allow specifying ' in the command string, making it hard to
protect the restore_command against problematic filenames (whitespace
etc.). This doesn't seem to be a problem for archive_command, which
allows \' (e.g.
On Tue, Dec 12, 2006 at 03:26:32PM -0500, Bruce Momjian wrote:
Heikki Linnakangas wrote:
The maintain_cluster_order patch is useful by itself, and handles an
existing TODO regarding pulling pages out of WAL in a specified order to
maintain clustering.
Pull pages out of WAL? That
On 2006-12-13, Tom Lane [EMAIL PROTECTED] wrote:
I wrote:
Right offhand I cannot see a reason why there should be different
equality operators with the same sortops. (If anyone can come up with
a plausible scenario for that, stop me here...)
BTW, I think it's possible to prove that there
Mark Kirkwood [EMAIL PROTECTED] writes:
I just noticed that defining LOCK_DEBUG causes a compile failure
Still another demonstration that Bruce's approach to removing unused
#includes does not work. Patched in HEAD ...
regards, tom lane
---(end
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2006-12-13, Tom Lane [EMAIL PROTECTED] wrote:
BTW, I think it's possible to prove that there need never be two for the
case of both sides the same datatype.
Counterexample even for a single data type: define an operator x =* y
which is true
On Fri, Dec 08, 2006 at 11:43:27AM -0500, Tom Lane wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
Jim C. Nasby [EMAIL PROTECTED] wrote:
Generally, I try and configure the all* settings so that you'll get 1
clock-sweep per checkpoint_timeout. It's worked pretty well, but I don't
have any
On 2006-12-13, Tom Lane [EMAIL PROTECTED] wrote:
Andrew - Supernews [EMAIL PROTECTED] writes:
On 2006-12-13, Tom Lane [EMAIL PROTECTED] wrote:
BTW, I think it's possible to prove that there need never be two for the
case of both sides the same datatype.
Counterexample even for a single data
Tom Lane wrote:
We change libpq from time to time. Besides, how many DBs are there
that
match the name pattern /^conn:.*=/ ? My guess is mighty few. So I
don't
expect lots of surprise.
Um, but how many DB names have an = in them at all?
Basically what this proposal is about is migrating
Hi All,
In ExplainOnePlan(), we are calling ExecutorStart() and ExecutorEnd()
even if we are not doing EXPLAIN ANALYZE. Whereas, ExecutorRun() is called
only if we are ANALYZEing.
Can we avoid calls to Executor{Start|End}() here, or is it necessary to
call them even for non-ANALYZE case?
55 matches
Mail list logo
