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

From ohp@pyrenet.fr
Subject Re: cvs head initdb hangs on unixware
Date
Msg-id Pine.UW2.4.63.0812091414520.29794@sun.pyrenet
Whole thread Raw
In response to Re: cvs head initdb hangs on unixware  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: cvs head initdb hangs on unixware
Re: cvs head initdb hangs on unixware
List 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@sss.pgh.pa.us>
> To: ohp@pyrenet.fr
> Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
>     Zdenek Kotala <Zdenek.Kotala@Sun.COM>,
>     pgsql-hackers list <pgsql-hackers@postgresql.org>
> Subject: Re: [HACKERS] cvs head initdb hangs on unixware 
> 
> ohp@pyrenet.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@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)


pgsql-hackers by date:

Previous
From: Grzegorz Jaskiewicz
Date:
Subject: Re: WIP: default values for function parameters
Next
From: Tom Lane
Date:
Subject: Re: operator does not exist: smallint <> smallint[]