Re: [HACKERS] cvs head initdb hangs on unixware

[ohp]

On Wed, 3 Dec 2008, Heikki Linnakangas wrote:

Date: Wed, 03 Dec 2008 20:29:01 +0200
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zdenek Kotala <[EMAIL PROTECTED]>,
    pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] cvs head initdb hangs on unixware

[EMAIL PROTECTED] wrote:

On Tue, 2 Dec 2008, Heikki Linnakangas wrote:

Date: Tue, 02 Dec 2008 20:47:19 +0200
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zdenek Kotala <[EMAIL PROTECTED]>,
    pgsql-hackers list <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] cvs head initdb hangs on unixware

[EMAIL PROTECTED] 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]

 [4] RelationGetBufferForTuple( présumé: 0x84b2250, 0xb4, 0) [0x8099b59]
 [5] heap_insert(0x84b2250, 0x853a338, 0, 0, 0) [0x8097042]

 [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!

[2] fsm_set_and_search(0x84b2250, 0, 0, 0x2e, 0x5, 0x6, 0x2e, 0x8047416, 0xb4) [0x81e6385] [3] RecordAndGetPageWithFreeSpace(0x84b2250, 0x2e, 0xa0, 0xb4) [0x81e5a00] [6] simple_heap_insert( présumé: 0x84b2250, 0x853a338, 0x853a310) [0x8097297] 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...

Hmm, it's probably looping in fsm_search_avail then. In a fresh cluster, there shouldn't be any broken FSM pages that need rebuilding.

You're right!

DEBUG: fixing corrupt FSM block 1, relation 123/456/789

I'd like to see what the FSM page in question looks like. Could you try to run initdb with "-d -n" options? I bet you'll get an infinite number of lines like:

right again!
DEBUG:  fixing corrupt FSM block 2, relation 1663/1/1255

Could you zip up the FSM file of that relation (a file called e.g "789_fsm"), and send it over? Or the whole data directory, it shouldn't be that big.

you get both.

BTW, this is an optimizer problem, not anything wrong with the code, but I'd hate to have a -g compiled postmaster in prod :)

best regards,
--
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: [EMAIL PROTECTED]
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)

1255_fsm
Description: fsm

db.tgz
Description: data dir

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers