| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | ohp(at)pyrenet(dot)fr |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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-08 02:57:21 |
| Message-ID: | 5692.1228705041@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
ohp(at)pyrenet(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2008-12-08 03:17:05 | Re: ALTER composite type does not work, but ALTER TABLE which ROWTYPE is used as a type - works fine |
| Previous Message | Alex Hunsaker | 2008-12-08 02:13:35 | Re: contrib/pg_stat_statements 1202 |