Re: cvs head initdb hangs on unixware - Mailing list pgsql-hackers

From Tom Lane
Subject Re: cvs head initdb hangs on unixware
Date
Msg-id 5692.1228705041@sss.pgh.pa.us
Whole thread Raw
In response to Re: cvs head initdb hangs on unixware  (ohp@pyrenet.fr)
Responses Re: cvs head initdb hangs on unixware  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
ohp@pyrenet.fr writes:
> As you can see in attached initdb.log, it seems fsm_search_avail is called 
> repeatedly and args are sort of looping...

That's expected, since the system is inserting a lot of tuples
successively.  What it looks like to me is that the failing call is the
first one where the initial test *doesn't* result in falling out
immediately.  So the probability is that there's something wrong with
the code that descends the tree.

Note that the all-zeroes pages in your dump are uninformative because
none of the real FSM data has been written to disk yet.  We can see
from this trace that the code is dealing with not-all-zero pages.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Alex Hunsaker"
Date:
Subject: Re: contrib/pg_stat_statements 1202
Next
From: "Robert Haas"
Date:
Subject: Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine