Re: cvs head initdb hangs on unixware

From: ohp(at)pyrenet(dot)fr
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-09 13:23:16
Message-ID: Pine.UW2.4.63.0812091414520.29794@sun.pyrenet
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,
On Mon, 8 Dec 2008, Tom Lane wrote:

> Date: Mon, 08 Dec 2008 13:15:28 -0500
> 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: [HACKERS] cvs head initdb hangs on unixware
>
> ohp(at)pyrenet(dot)fr writes:
>> the infinite loop occurs in fsm_search_avail when called for the 32nd
>> time.
>
> ... which is the first time that the initial test doesn't make it fall
> out immediately.
>
> Would you add a couple more printouts, along the line of
>
>
> nodeno = target;
> while (nodeno > 0)
> {
> + fprintf(stderr, "ascend at node %d value %d\n",
> + nodeno, fsmpage->fp_nodes[nodeno]);
>
> if (fsmpage->fp_nodes[nodeno] >= minvalue)
> break;
>
> /*
> * Move to the right, wrapping around on same level if necessary,
> * then climb up.
> */
> nodeno = parentof(rightneighbor(nodeno));
> }
>
> /*
> * We're now at a node with enough free space, somewhere in the middle of
> * the tree. Descend to the bottom, following a path with enough free
> * space, preferring to move left if there's a choice.
> */
> while (nodeno < NonLeafNodesPerPage)
> {
> int leftnodeno = leftchild(nodeno);
> int rightnodeno = leftnodeno + 1;
> bool leftok = (leftnodeno < NodesPerPage) &&
> (fsmpage->fp_nodes[leftnodeno] >= minvalue);
> bool rightok = (rightnodeno < NodesPerPage) &&
> (fsmpage->fp_nodes[rightnodeno] >= minvalue);
>
> + fprintf(stderr, "descend at node %d value %d, leftnode %d value %d, rightnode %d value %d\n",
> + nodeno, fsmpage->fp_nodes[nodeno],
> + leftnodeno, fsmpage->fp_nodes[leftnodeno],
> + rightnodeno, fsmpage->fp_nodes[rightnodeno]);
>
> if (leftok)
> nodeno = leftnodeno;
> else if (rightok)
> nodeno = rightnodeno;
> else
>
> (I'm assuming we can print possibly-off-the-end array elements without dumping
> core; which is bogus in general but I expect we can get away with it
> for this purpose.)
>
> Also, we don't really need 94MB of log to convince us it's an
> infinite loop ;-)
oops, sorry
>
> regards, tom lane
>
I first misread your mail, and added only the first fprintf , while I was
uploading a 400M initdb.log, I went back to add the second one.

Guess what! with the fprintf .. descending node... in place, everything
goes well. The optimizer definitly does something weird along the
definition/assignement of leftok/rightok..

--
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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-09 13:24:34 Re: operator does not exist: smallint <> smallint[]
Previous Message Grzegorz Jaskiewicz 2008-12-09 13:16:19 Re: WIP: default values for function parameters