Обсуждение: Re: [HACKERS] LIMITS
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
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
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
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
> 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, Pennsylvania19026
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) #
> 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, Pennsylvania19026
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
> 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, Pennsylvania19026
>
> > 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) #
> 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,
Pennsylvania19026