I just did a CVS update on the current version of Postgres.

I loaded in my database, and then I tried to dump the database. 
I got this error....

getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
Bad type 0
'.

--
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com

Tue, 01 Jun 1999 21:22:48 +1000
Chris Bitmead <chris.bitmead@bigfoot.com>
Re: [HACKERS] LIMITS
Chris Bitmead <chris.bitmead@bigfoot.com> writes:
> getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
> Bad type 0
> '.

Did you do a full recompile and initdb?

			regards, tom lane

Tue, 01 Jun 1999 10:33:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] LIMITS 
Tom Lane wrote:
> 
> Chris Bitmead <chris.bitmead@bigfoot.com> writes:
> > getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
> > Bad type 0
> > '.
> 
> Did you do a full recompile and initdb?

I did a full compile,  but I didn't do an initdb. I was upgrading from a
6.5 beta of about a month ago to the latest CVS. Should it be necessary?

-- 
Chris Bitmead
http://www.bigfoot.com/~chris.bitmead
mailto:chris.bitmead@bigfoot.com

Wed, 02 Jun 1999 00:42:50 +1000
Chris Bitmead <chris.bitmead@bigfoot.com>
Re: [HACKERS] LIMITS
> Tom Lane wrote:
> > 
> > Chris Bitmead <chris.bitmead@bigfoot.com> writes:
> > > getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
> > > Bad type 0
> > > '.
> > 
> > Did you do a full recompile and initdb?
> 
> I did a full compile,  but I didn't do an initdb. I was upgrading from a
> 6.5 beta of about a month ago to the latest CVS. Should it be necessary?

You bet.  Technically, we don't like to change the database during
beta's, but for 6.5beta, we have had to several times.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Jun 1999 11:15:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] LIMITS
Chris Bitmead <chris.bitmead@bigfoot.com> writes:
>> Did you do a full recompile and initdb?

> I did a full compile,  but I didn't do an initdb. I was upgrading from a
> 6.5 beta of about a month ago to the latest CVS. Should it be necessary?

Yes, I recall someone (Jan?) changed a couple of node types recently.
That affects the stored representation of rules among other things.

It's considered courteous to mention it in the hackers list when you
do something that requires a full recompile and/or initdb, but a quick
note is likely to be all the notice there is for such changes on the
current sources.

If you're not paying close attention to pghackers traffic, the safest
approach is make distclean, rebuild, initdb every time you pull current
sources.  I do that routinely, even though I pull sources every few
days.  Machine time is cheap; wasted debugging effort is not.


Memo to hackers: it might be nice to have some sort of "INITDB serial
number" value somewhere that could be bumped anytime someone makes an
initdb-forcing change; then the postmaster could refuse to start up
if you are trying to run it against an incompatible database.  As far
as I know we do this at the granularity of major releases, but it'd be
even more useful with a finer-grained serial number...

			regards, tom lane

Tue, 01 Jun 1999 11:17:33 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] LIMITS 
Chris Bitmead wrote:

>
> Tom Lane wrote:
> >
> > Chris Bitmead <chris.bitmead@bigfoot.com> writes:
> > > getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
> > > Bad type 0
> > > '.
> >
> > Did you do a full recompile and initdb?
>
> I did a full compile,  but I didn't do an initdb. I was upgrading from a
> 6.5 beta of about a month ago to the latest CVS. Should it be necessary?

    I think we shouldn't call anything BETA until it is released.
    The current CVS tree has ALPHA state.

    Until the official release (when  Marc  rolls  the  tarball),
    development  can  cause all kind of changes, including schema
    changes   to   system    catalogs,    print    strings    for
    parsetrees/plans  etc.  Those  changes  require an initdb run
    because the db files aren't binary compatible any more or the
    corresponding node read functions aren't able to get back the
    right trees from the  string  representations  found  in  the
    catalogs.

    Until  Marc  officially  releases  BETA,  you  should allways
    compile clean and run initdb after cvs updates. It's not  the
    first time you've got trapped by this.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Tue, 1 Jun 1999 17:39:12 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LIMITS
> Chris Bitmead wrote:
> 
> >
> > Tom Lane wrote:
> > >
> > > Chris Bitmead <chris.bitmead@bigfoot.com> writes:
> > > > getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
> > > > Bad type 0
> > > > '.
> > >
> > > Did you do a full recompile and initdb?
> >
> > I did a full compile,  but I didn't do an initdb. I was upgrading from a
> > 6.5 beta of about a month ago to the latest CVS. Should it be necessary?
> 
>     I think we shouldn't call anything BETA until it is released.
>     The current CVS tree has ALPHA state.
> 
>     Until the official release (when  Marc  rolls  the  tarball),
>     development  can  cause all kind of changes, including schema
>     changes   to   system    catalogs,    print    strings    for
>     parsetrees/plans  etc.  Those  changes  require an initdb run
>     because the db files aren't binary compatible any more or the
>     corresponding node read functions aren't able to get back the
>     right trees from the  string  representations  found  in  the
>     catalogs.
> 
>     Until  Marc  officially  releases  BETA,  you  should allways
>     compile clean and run initdb after cvs updates. It's not  the
>     first time you've got trapped by this.

But we have been in beta officially since at least May 1.  Why is this
not beta?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Jun 1999 11:53:22 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] LIMITS
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Until  Marc  officially  releases  BETA,  you  should allways
>> compile clean and run initdb after cvs updates. It's not  the
>> first time you've got trapped by this.

> But we have been in beta officially since at least May 1.  Why is this
> not beta?

I think Jan's point is that what we call a beta is not as stable as
what other people call a beta, and that calling the test releases
alpha releases would convey a more accurate impression of their
stability.  I don't agree, but he's got a tenable position.

			regards, tom lane

Tue, 01 Jun 1999 12:30:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] LIMITS 
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> Until  Marc  officially  releases  BETA,  you  should allways
> >> compile clean and run initdb after cvs updates. It's not  the
> >> first time you've got trapped by this.
> 
> > But we have been in beta officially since at least May 1.  Why is this
> > not beta?
> 
> I think Jan's point is that what we call a beta is not as stable as
> what other people call a beta, and that calling the test releases
> alpha releases would convey a more accurate impression of their
> stability.  I don't agree, but he's got a tenable position.

I don't think our betas are less stable, but the dump/reload requirement
is clearly not something for a beta release.  We _usually_ get through a
beta release without such changes, but the MVCC stuff has required it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Jun 1999 12:33:23 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] LIMITS
>
> > Chris Bitmead wrote:
> >
> > >
> > > Tom Lane wrote:
> > > >
> > > > Chris Bitmead <chris.bitmead@bigfoot.com> writes:
> > > > > getTypes(): SELECT failed.  Explanation from backend: 'ERROR:  nodeRead:
> > > > > Bad type 0
> > > > > '.
> > > >
> > > > Did you do a full recompile and initdb?
> > >
> > > I did a full compile,  but I didn't do an initdb. I was upgrading from a
> > > 6.5 beta of about a month ago to the latest CVS. Should it be necessary?
> >
> >     I think we shouldn't call anything BETA until it is released.
> >     The current CVS tree has ALPHA state.
> >
> >     Until the official release (when  Marc  rolls  the  tarball),
> >     development  can  cause all kind of changes, including schema
> >     changes   to   system    catalogs,    print    strings    for
> >     parsetrees/plans  etc.  Those  changes  require an initdb run
> >     because the db files aren't binary compatible any more or the
> >     corresponding node read functions aren't able to get back the
> >     right trees from the  string  representations  found  in  the
> >     catalogs.
> >
> >     Until  Marc  officially  releases  BETA,  you  should allways
> >     compile clean and run initdb after cvs updates. It's not  the
> >     first time you've got trapped by this.
>
> But we have been in beta officially since at least May 1.  Why is this
> not beta?

    If  fact  it  is  -  right buddy - but some {loo|u}sers think
    "BETA" is something ready for use with the risk of having  to
    install some bugfixes later. But using our BETA might require
    to dump/reload and that's not simply installing a fix.

    It all has to do with how we handle our BETA phase. I know, I
    was  myself one of those who caused an initdb during this. It
    was required for one of our TODO's for v6.5.

    In the future, at the moment we want to declare  current  CVS
    beeing  BETA,  we  should  identify all those TODO items that
    potentially require an initdb and decide upon  them  if  they
    have  to  go  into  the  next release or if they cause a BETA
    delay. After we declared BETA, any TODO item that requires an
    initdb must by default go into the next release. Closed shop!


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #



Tue, 1 Jun 1999 19:27:25 +0200 (MET DST)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] LIMITS
>     If  fact  it  is  -  right buddy - but some {loo|u}sers think
>     "BETA" is something ready for use with the risk of having  to
>     install some bugfixes later. But using our BETA might require
>     to dump/reload and that's not simply installing a fix.
> 
>     It all has to do with how we handle our BETA phase. I know, I
>     was  myself one of those who caused an initdb during this. It
>     was required for one of our TODO's for v6.5.
> 
>     In the future, at the moment we want to declare  current  CVS
>     beeing  BETA,  we  should  identify all those TODO items that
>     potentially require an initdb and decide upon  them  if  they
>     have  to  go  into  the  next release or if they cause a BETA
>     delay. After we declared BETA, any TODO item that requires an
>     initdb must by default go into the next release. Closed shop!

We usually discourage any initdb changes in beta, but we have had so
many required ones, it we didn't make any big deal about it in 6.5.

I belive earlier releases have not required dump/reload in beta.  I know
it has happened only a few times in three years.  6.5 did it a lot,
partially because we now understand so much more, and are mucking/fixing
so much more detailed code.

It is clearly more than an alpha, were we expect serious breakage.  We
have a list of clearly-defined bugs for the release.  Maybe we call it
beta-light.  Also, we require beta people to be on the hackers list, so
they can know of dump/reload, so it is sort of a subscriber beta.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 1 Jun 1999 13:37:00 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] LIMITS