Обсуждение: main tree is (slightly) damaged

I've got trouble in a *clean* checkout of this morning's current tree.
Something in the system tables is not quite consistant:

postgres=> \d
ERROR:  nodeRead: Bad type 0

Also, I'm getting failures in regression tests:

constraints .. failed
>From a bunch of similar messages; related to above symptom?:
ERROR:  nodeRead: Bad type 0

sanity_check .. failed
One extra message during first vacuum:
ERROR:  nodeRead: Bad type 0

misc .. failed
Different ordering in output. Wonder why it changed?

select_views .. failed
ERROR:  nodeRead: Bad type 0

rules .. failed
ERROR:  nodeRead: Bad type 0

plpgsql .. failed
Formatting for rows has changed in psql? Or something with plpgsql has
changed the contents? I haven't tried tracking this down.
976c976
< slotname            |roomno  |slotlink           
|backlink            
---
> slotname            |  roomno|            slotlink|backlink            

Do any other platforms run the tests without trouble? Does anyone have
a guess at when and/or what broke?? I'm running on linux-2.0.36/RH5.2
using the as-shipped compiler.
                  - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

************

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I've got trouble in a *clean* checkout of this morning's current tree.
> Something in the system tables is not quite consistant:
> postgres=> \d
> ERROR:  nodeRead: Bad type 0

Yipes.  Perhaps there is some platform-dependency in the md.c changes
I committed a couple days ago.  I am not seeing any such problems,
but that doesn't prove a lot.  How far back was the last version
that worked on your system?

> Formatting for rows has changed in psql? Or something with plpgsql has
> changed the contents? I haven't tried tracking this down.
> 976c976
> < slotname            |roomno  |slotlink            |backlink            
> ---
> > slotname            |  roomno|            slotlink|backlink            

I made some changes in fe-print.c's code that decides whether a column
contains numeric data (and hence should be right justified), but it
didn't break the regress tests for me...

> Do any other platforms run the tests without trouble?

HPUX 9 here.  This is a big-endian box; maybe a byte ordering issue?
        regards, tom lane

> > I've got trouble in a *clean* checkout of this morning's current tree.
> > Something in the system tables is not quite consistant:
> > postgres=> \d
> > ERROR:  nodeRead: Bad type 0
> Yipes.  Perhaps there is some platform-dependency in the md.c changes
> I committed a couple days ago.  I am not seeing any such problems,
> but that doesn't prove a lot.  How far back was the last version
> that worked on your system?
> > Do any other platforms run the tests without trouble?
> HPUX 9 here.  This is a big-endian box; maybe a byte ordering issue?

postgres=> select * from pg_tables;
ERROR:  nodeRead: Bad type 0

I still see a problem. Did a "make clean install; initdb", as well as
a clean checkout of the current source tree from cvsup.

Is anyone else running regression tests besides the Toms? Can someone
report success on a linux box? Don't know where the problems are
coming from...

I'm sure I ran the regression tests around the v6.5.1 release date,
but haven't been doing code development since then (working on docs
instead) so haven't been testing...
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> postgres=> select * from pg_tables;
> ERROR:  nodeRead: Bad type 0

> I still see a problem. Did a "make clean install; initdb", as well as
> a clean checkout of the current source tree from cvsup.

Drat.  I was really hoping that you'd just forgotten initdb --- the
parsetree changes I made a couple weeks ago could have explained this,
but not if you initdb'd.

The failure is presumably coming from an attempt to read a stored rule
or default-value clause that's not stored in the format that the read
procedures are expecting.  I'm guessing that there is a node write proc
that's not the inverse of the corresponding node read proc, and you
happen to have a rule or default that has the right kind of node in it
to expose the bug.

Could you burrow in with a debugger and find out more about the rule or
default that's triggering the error?
        regards, tom lane

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> postgres=> select * from pg_tables;
> ERROR:  nodeRead: Bad type 0

Ah-hah.  I was able to duplicate this problem on a local Linux box.
It seems that some implementations of vsnprintf() return -1 when the
data doesn't fit in the available space, rather than the size of the
available space as the man page specifies.  This broke my recent
revision of stringinfo.c.  Grumble.  Will commit a fix shortly.
        regards, tom lane