Re: New dot releases

Hi,

After / before 8.1 Beta 2, are there any plans to release new dot releases
for the back branches?

Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Devrim Gunduz <devrim(at)gunduz(dot)org> writes:
> After / before 8.1 Beta 2, are there any plans to release new dot releases
> for the back branches?

Some day ;-)

What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
right after I patched the vacuum/ctid-chain stuff. That probably
indicates a problem, but the owner of the machine has been completely
unhelpful about providing any information to track it down.

regards, tom lane

>What's holding up the back branches at the moment is that the gerbil
>buildfarm member is showing failures in the 8.0 branch that started
>right after I patched the vacuum/ctid-chain stuff. That probably
>indicates a problem, but the owner of the machine has been completely
>unhelpful about providing any information to track it down.
>
>
I have a Solaris 9 machine on Sparc that I could let you have
access to. Would that help?

Sincerely,

Joshua D. Drake

> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

On Fri, Sep 16, 2005 at 07:57:08AM -0700, Joshua D. Drake wrote:
> >What's holding up the back branches at the moment is that the gerbil
> >buildfarm member is showing failures in the 8.0 branch that started
> >right after I patched the vacuum/ctid-chain stuff. That probably
> >indicates a problem, but the owner of the machine has been completely
> >unhelpful about providing any information to track it down.
> >
> I have a Solaris 9 machine on Sparc that I could let you have
> access to. Would that help?

FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
test REL8_0_STABLE with gerbil's configure options when I get a
chance.

Most of gerbil's errors are:

creating information schema ... Bus Error - core dumped

but a few are:

creating template1 database in /home/pgbuildfarm/build-farm-2.05/REL8_0_STABLE/pgsql.5942/src/test/regress/./tmp_check/data/base/1 ... FATAL: shmat(id=8326) failed: Not enough space

--
Michael Fuhr

On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote:
> FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
> gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
> test REL8_0_STABLE with gerbil's configure options when I get a
> chance.

I just built REL8_0_STABLE with the following configure options
(same as gerbil):

./configure --enable-cassert --enable-debug --enable-nls \
--enable-integer-datetimes --with-perl --with-python \
--with-openssl --with-pgport=5682

gmake check returned the following:

======================
All 96 tests passed.
======================

--
Michael Fuhr

Hi,

On Fri, 16 Sep 2005, Michael Fuhr wrote:

> On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote:
>> FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
>> gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
>> test REL8_0_STABLE with gerbil's configure options when I get a
>> chance.
>
> I just built REL8_0_STABLE with the following configure options
> (same as gerbil):
>
> ./configure --enable-cassert --enable-debug --enable-nls \
> --enable-integer-datetimes --with-perl --with-python \
> --with-openssl --with-pgport=5682
>
> gmake check returned the following:
>
> ======================
> All 96 tests passed.
> ======================

So no need to hold the new dot releases? :)

I want to work on new RPM sets and don't want to apply countless
patches... :)

Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
>From pgsql-hackers-owner(at)postgresql(dot)org Mon Sep 19 11:27:58 2005
X-Original-To: pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (av.hub.org [200.46.204.144])
by svr1.postgresql.org (Postfix) with ESMTP id 0556DD9369
for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Mon, 19 Sep 2005 11:27:57 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
with ESMTP id 84481-05
for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>;
Mon, 19 Sep 2005 14:27:44 +0000 (GMT)
Received: from mx03.kabsi.at (mx03.kabsi.at [195.202.128.130])
by svr1.postgresql.org (Postfix) with ESMTP id E2D85D92FB
for <pgsql-hackers(at)postgresql(dot)org>; Mon, 19 Sep 2005 11:27:44 -0300 (ADT)
Received: from [192.168.0.5] (h062040243020.plc.cm.kabsi.at [62.40.243.20])
by mx03.kabsi.at (8.13.3/8.13.3) with ESMTP id j8JERlm6020025
for <pgsql-hackers(at)postgresql(dot)org>; Mon, 19 Sep 2005 16:27:47 +0200
Message-ID: <432ECAE2(dot)7070805(at)cybertec(dot)at>
Date: Mon, 19 Sep 2005 16:27:46 +0200
From: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres(at)cybertec(dot)at>
User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pgsql-hackers(at)postgresql(dot)org
Subject: DISTINCT vs. GROUP BY
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.01 required=5 tests=[AWL=0.010]
X-Spam-Level:
X-Archive-Number: 200509/808
X-Sequence-Number: 73205

I was wondering whether it is possible to teach the planner to handle
DISTINCT in a more efficient way:

em=# explain select distinct lastname from import.testtest;
QUERY PLAN
--------------------------------------------------------------------------------
Unique (cost=2647377.45..2709467.70 rows=1 width=7)
-> Sort (cost=2647377.45..2678422.58 rows=12418051 width=7)
Sort Key: lastname
-> Seq Scan on testtest (cost=0.00..370082.51 rows=12418051
width=7)
(4 Zeilen)

Isn't it possible to perform the same operation using a HashAggregate?
We have seen that a GROUP BY workaround is usually a lot faster than
sort->unique - at least when work_mem is large enough.

best regards,

hans

--
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at

Devrim GUNDUZ <devrim(at)gunduz(dot)org> writes:
> So no need to hold the new dot releases? :)

I still object to releasing them until we find out what's going on
on gerbil. That machine was building 8.0 fine until the patch, and it's
failing consistently since then. To assume this is not our problem
would be the height of hubris.

regards, tom lane

On Mon, Sep 19, 2005 at 10:53:44AM -0400, Tom Lane wrote:
> Devrim GUNDUZ <devrim(at)gunduz(dot)org> writes:
> > So no need to hold the new dot releases? :)
>
> I still object to releasing them until we find out what's going on
> on gerbil. That machine was building 8.0 fine until the patch, and it's
> failing consistently since then. To assume this is not our problem
> would be the height of hubris.

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?

Most of gerbil's failures are:

creating information schema ... Bus Error - core dumped

Is the message implying that the postgres process that initdb starts
is dumping core? Any ideas on how the patch might cause that?

The most recent failures are

shmat(id=8326) failed: Not enough space

and the default settings are

selecting default max_connections ... 10
selecting default shared_buffers ... 50

Earlier tests that got as far as "creating information schema" had
defaults lower than the maximums:

selecting default max_connections ... 40
selecting default shared_buffers ... 700

Could the reduced settings (and thus what they imply about the
amount of shared memory) be relevant? Could anything in the patch
be affected by that? If you think it might be worthwhile, I could
mess around with my box's shared memory settings and test it.

Just looking for differences between gerbil and my box....

--
Michael Fuhr

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 had been working on this trying (unsucessfully) to get a working
backtrace when I ended up with a bunch of other things on my plate. We
now have a good backtrace.

> Most of gerbil's failures are:
>
> creating information schema ... Bus Error - core dumped
>
> Is the message implying that the postgres process that initdb starts
> is dumping core? Any ideas on how the patch might cause that?
>
> The most recent failures are
>
> shmat(id=8326) failed: Not enough space

The shmat errors were because there were a bunch of shared memory
segments hanging around, because they didn't get cleaned up from
initdb coreing. The only real issue is the core dump, which an email has
been sent to the list about.

Sorry for the delay in tracking this down.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461