Re: [HACKERS] LIMITS - Mailing list pgsql-hackers
From | wieck@debis.com (Jan Wieck) |
---|---|
Subject | Re: [HACKERS] LIMITS |
Date | |
Msg-id | m10osJx-0003kGC@orion.SAPserv.Hamburg.dsh.de Whole thread Raw |
In response to | Re: [HACKERS] LIMITS (Bruce Momjian <maillist@candle.pha.pa.us>) |
Responses |
Re: [HACKERS] LIMITS
|
List | pgsql-hackers |
> > > 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) #
pgsql-hackers by date: