Thread: 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