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: cvs head initdb hangs on unixware |
Date: | 2008-12-04 11:19:15 |
Message-ID: | 4937BCB3.8060302@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ohp(at)pyrenet(dot)fr wrote:
> On Wed, 3 Dec 2008, Heikki Linnakangas wrote:
>> 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.
Thanks. Hmm, the FSM pages are full of zeros, as I would expect for a
just-created relation. fsm_search_avail should've returned quickly at
the top of the function in that case. Can you put a extra printf or
something at the top of the function, to print all the arguments? And
the value of fsmpage->fp_nodes[0].
> BTW, this is an optimizer problem, not anything wrong with the code, but
> I'd hate to have a -g compiled postmaster in prod :)
Yes, so it seems, although I wouldn't be surprised if it turns out to be
a bug in the new FSM code either..
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-12-04 11:21:10 | Re: In-place upgrade: catalog side |
Previous Message | ohp | 2008-12-04 10:57:52 | Re: cvs head initdb hangs on unixware |