Re: cvs head initdb hangs on unixware

On Tue, 2 Dec 2008, Heikki Linnakangas wrote:

> Date: Tue, 02 Dec 2008 20:47:19 +0200
> From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
> To: ohp(at)pyrenet(dot)fr
> Cc: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>,
> pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
> Subject: Re: [HACKERS] cvs head initdb hangs on unixware
>
> ohp(at)pyrenet(dot)fr wrote:
>> Suivi de pile correspondant à p1, Programme postmaster
>> *[0] fsm_rebuild_page( présumé: 0xbd9731a0, 0, 0xbd9731a0) [0x81e6a97]
>> [1] fsm_search_avail( présumé: 0x2, 0x6, 0x1) [0x81e68d9]
>> [2] fsm_set_and_search(0x84b2250, 0, 0, 0x2e, 0x5, 0x6, 0x2e, 0x8047416,
>> 0xb4) [0x81e6385]
>> [3] RecordAndGetPageWithFreeSpace(0x84b2250, 0x2e, 0xa0, 0xb4) [0x81e5a00]
>> [4] RelationGetBufferForTuple( présumé: 0x84b2250, 0xb4, 0) [0x8099b59]
>> [5] heap_insert(0x84b2250, 0x853a338, 0, 0, 0) [0x8097042]
>> [6] simple_heap_insert( présumé: 0x84b2250, 0x853a338, 0x853a310)
>> [0x8097297]
>> [7] InsertOneTuple( présumé: 0xb80, 0x84057b0, 0x8452fb8) [0x80cb210]
>> [8] boot_yyparse( présumé: 0xffffffff, 0x3, 0x8047ab8) [0x80c822b]
>> [9] BootstrapModeMain( présumé: 0x66, 0x8454600, 0x4) [0x80ca233]
>> [10] AuxiliaryProcessMain(0x4, 0x8047ab4) [0x80cab3b]
>> [11] main(0x4, 0x8047ab4, 0x8047ac8) [0x8177dce]
>> [12] _start() [0x807ff96]
>>
>> seems interesting!
>>
>> We've had problems already with unixware optimizer, hope this one is
>> fixable!
>
> Looking at fsm_rebuild_page, I wonder if the compiler is treating "int" as an
> unsigned integer? That would cause an infinite loop.
>
>
No, a simple printf of nodeno shows it starting at 4096 all the way down
to 0, starting back at 4096...

I wonder if leftchild/rightchild definitions has something to do with
it...

--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp(at)pyrenet(dot)fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
>From pgsql-hackers-owner(at)postgresql(dot)org Wed Dec 3 09:23:34 2008
Received: from localhost (unknown [200.46.204.183])
by mail.postgresql.org (Postfix) with ESMTP id A2EDE650014
for <pgsql-hackers-postgresql(dot)org(at)mail(dot)postgresql(dot)org>; Wed, 3 Dec 2008 09:23:33 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
with ESMTP id 87376-09
for <pgsql-hackers-postgresql(dot)org(at)mail(dot)postgresql(dot)org>;
Wed, 3 Dec 2008 09:23:31 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169])
by mail.postgresql.org (Postfix) with ESMTP id 5948264FEBD
for <pgsql-hackers(at)postgresql(dot)org>; Wed, 3 Dec 2008 09:23:29 -0400 (AST)
Received: by ug-out-1314.google.com with SMTP id k40so3309484ugc.7
for <pgsql-hackers(at)postgresql(dot)org>; Wed, 03 Dec 2008 05:23:28 -0800 (PST)
Received: by 10.210.52.15 with SMTP id z15mr15406978ebz.19.1228310607851;
Wed, 03 Dec 2008 05:23:27 -0800 (PST)
Received: from ?80.223.223.193? (dsl-hkibrasgw2-fedfdf00-193.dhcp.inet.fi [80.223.223.193])
by mx.google.com with ESMTPS id h6sm35338289nfh.21.2008.12.03.05.23.24
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Wed, 03 Dec 2008 05:23:25 -0800 (PST)
Message-ID: <4936884B(dot)6050205(at)enterprisedb(dot)com>
Date: Wed, 03 Dec 2008 15:23:23 +0200
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
CC: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Visibility map, partial vacuums
References: <4905AE17(dot)7090305(at)enterprisedb(dot)com> <491D376B(dot)9000608(at)enterprisedb(dot)com> <491D7F52(dot)6070908(at)enterprisedb(dot)com> <4925664C(dot)3090605(at)enterprisedb(dot)com> <26361(dot)1227467112(at)sss(dot)pgh(dot)pa(dot)us> <492A6032(dot)6080000(at)enterprisedb(dot)com> <18086(dot)1227537479(at)sss(dot)pgh(dot)pa(dot)us> <492D4460(dot)1000809(at)enterprisedb(dot)com> <5856(dot)1227705135(at)sss(dot)pgh(dot)pa(dot)us> <492EF88F(dot)9050709(at)enterprisedb(dot)com>
In-Reply-To: <492EF88F(dot)9050709(at)enterprisedb(dot)com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level:
X-Archive-Number: 200812/147
X-Sequence-Number: 128776

Heikki Linnakangas wrote:
> Here's an updated version, with a lot of smaller cleanups, and using
> relcache invalidation to notify other backends when the visibility map
> fork is extended. I already committed the change to FSM to do the same.
> I'm feeling quite satisfied to commit this patch early next week.

Committed.

I haven't done any doc changes for this yet. I think a short section in
the "database internal storage" chapter is probably in order, and the
fact that plain VACUUM skips pages should be mentioned somewhere. I'll
skim through references to vacuum and see what needs to be changed.

Hmm. It just occurred to me that I think this circumvented the
anti-wraparound vacuuming: a normal vacuum doesn't advance relfrozenxid
anymore. We'll need to disable the skipping when autovacuum is triggered
to prevent wraparound. VACUUM FREEZE does that already, but it's
unnecessarily aggressive in freezing.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com