Thread: And to make things even better...
/var/lib/pgsql reports that we're running 6.3 - which I don't find on the FTP site. Is that not a valid distribution number, or is the source not available? steve
Steve Wolfe wrote: > /var/lib/pgsql reports that we're running 6.3 - which I don't find on the > FTP site. Is that not a valid distribution number, or is the source not > available? Oh, I remember running 6.3. That was a looong time ago. Current version is 6.5.3 and 7.0 is about to be released. I would very much recommend an upgrade, although you may want to wait for 7.0 to be released. I've been migrating stuff accross to 7.0 RC1 (release candidate) and it is pretty solid and a vast improvement on 6.3! Adriaan
> > /var/lib/pgsql reports that we're running 6.3 - which I don't find on the > > FTP site. Is that not a valid distribution number, or is the source not > > available? > > Oh, I remember running 6.3. That was a looong time ago. Current version is > 6.5.3 and 7.0 is about to be released. I would very much recommend an upgrade, > although you may want to wait for 7.0 to be released. I've been migrating > stuff accross to 7.0 RC1 (release candidate) and it is pretty solid and a vast > improvement on 6.3! I'd also like to do an upgrade - however, I've never done an upgrade before, there was a death in the family this morning, all of the programmers are dead in the water until this is fixed, and we can't go to the beta version just yet. So, I was hoping to have a fairly quick-fix for this. sigh.... what a day. : ) steve
Well, I bit the bullet and upgraded, and it was a fairly painless procedure. Thanks again for the help... steve
At 12:11 PM 19-04-2000 -0600, Steve Wolfe wrote: > > /var/lib/pgsql reports that we're running 6.3 - which I don't find on the >FTP site. Is that not a valid distribution number, or is the source not >available? Maybe the new guy did a make and linked the ancient 6.3 stuff in to Perl. I suspect that you were in fact running 6.5.3. But now some stuff is going to 6.3. Check your postgres data directory, I believe you can find the version number there. Once you have confirmed the version you are really using, you can use the correct binaries to back up/dump your data. Please check the docs on what actually is dumped - certain things may not be dumped correctly depending on which version you are using. If you are daring you could "schedule" an upgrade to Postgresql 7.0. Hey since it's already down and you have to recompile stuff <grin>. I'm kidding of course, well half kidding. Cheerio, Link.
> > /var/lib/pgsql reports that we're running 6.3 - which I don't find on the > >FTP site. Is that not a valid distribution number, or is the source not > >available? > > Maybe the new guy did a make and linked the ancient 6.3 stuff in to Perl. > > I suspect that you were in fact running 6.5.3. But now some stuff is going > to 6.3. Nope, it was bona-fide 6.3. : ) > Check your postgres data directory, I believe you can find the version > number there. That's where I found that. : ) > Once you have confirmed the version you are really using, you can use the > correct binaries to back up/dump your data. Please check the docs on what > actually is dumped - certain things may not be dumped correctly depending > on which version you are using. Part of the problem that I ran into was that the old guy had copied most of the binaries from ~postgres/bin to other directories to get them in the path. So, even after I wiped out the 6.3 directory and compiled 6.5.3, when I'd do "initdb", it would create a 6.3 database structure, and make everything barf. Fun, no? steve
One last problem - after upgrading to 6.5.3, psql no longer seems to be
using the readline stuff for going through the command history, all we get
are the funky control characters ("^[[A^[[A", etc.) Any info on how to
make it work?
Oh, yes, it seems like 6.5.3 is more strict about not allowing you to use
reserved words for field names. Some nimrod had created a table with field
names 'time' and 'date', boy, did that make trying to restore fun, fun,
fun.....
steve
I've got the same problem with readline and psql using 7.0 RC1.
I found that there was something odd when ran configure. Here's the
readline stuff I grepped out of config.cache:
ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}
Notice that the first line still says "no". Looks to me like it wants to
find readline.h in /usr/include, as well as, /usr/include/readline. Could
this be the source of the problem?
-=michael=-
*****************************************************
* Michael S. Kelly
* 4800 SW Griffith Dr., Ste. 202
* Beaverton, OR 97005 USA
* voice: (503)644-6106 x122 fax: (503)643-8425
* <michaelk@axian.com>
* http://www.axian.com/
*****************************************************
* Axian: Software Consulting and Training
*****************************************************
-----Original Message-----
From: Steve Wolfe [mailto:steve@iboats.com]
Sent: Thursday, April 20, 2000 9:51 AM
To: pgsql-general@postgresql.org
Subject: One last thing... psql and readline
One last problem - after upgrading to 6.5.3, psql no longer seems to be
using the readline stuff for going through the command history, all we get
are the funky control characters ("^[[A^[[A", etc.) Any info on how to
make it work?
Oh, yes, it seems like 6.5.3 is more strict about not allowing you to use
reserved words for field names. Some nimrod had created a table with field
names 'time' and 'date', boy, did that make trying to restore fun, fun,
fun.....
steve
> I've got the same problem with readline and psql using 7.0 RC1.
>
> I found that there was something odd when ran configure. Here's the
> readline stuff I grepped out of config.cache:
>
> ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
>
ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
>
ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
> ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
>
ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}
>
> Notice that the first line still says "no". Looks to me like it wants to
> find readline.h in /usr/include, as well as, /usr/include/readline.
Could
> this be the source of the problem?
Interesting observation, thanks for following up. In my case, I gave up
(since the machine that needed the emergency upgrade was slightly
whacked-out), and copied the psql binary from a different machine, a Redhat
6.1 setup, where the readline stuff compiled succesfully. Sorry I can't be
of more help.... well, let me see...
On the system where it compiled succesfully, readline.h is only found in
/usr/include/readline/readline.h.
steve
I don't really follow how configure works (yet), however, I think this may be an
"OR" rather than an "AND". I believe (!) that different version of readline did
this differently and that is what is being checked for.
Mark
"Michael S. Kelly" wrote:
> I've got the same problem with readline and psql using 7.0 RC1.
>
> I found that there was something odd when ran configure. Here's the
> readline stuff I grepped out of config.cache:
>
> ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
> ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
> ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
> ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
> ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}
>
> Notice that the first line still says "no". Looks to me like it wants to
> find readline.h in /usr/include, as well as, /usr/include/readline. Could
> this be the source of the problem?
>
> -=michael=-
>
> *****************************************************
> * Michael S. Kelly
> * 4800 SW Griffith Dr., Ste. 202
> * Beaverton, OR 97005 USA
> * voice: (503)644-6106 x122 fax: (503)643-8425
> * <michaelk@axian.com>
> * http://www.axian.com/
> *****************************************************
> * Axian: Software Consulting and Training
> *****************************************************
>
> -----Original Message-----
> From: Steve Wolfe [mailto:steve@iboats.com]
> Sent: Thursday, April 20, 2000 9:51 AM
> To: pgsql-general@postgresql.org
> Subject: One last thing... psql and readline
>
> One last problem - after upgrading to 6.5.3, psql no longer seems to be
> using the readline stuff for going through the command history, all we get
> are the funky control characters ("^[[A^[[A", etc.) Any info on how to
> make it work?
>
> Oh, yes, it seems like 6.5.3 is more strict about not allowing you to use
> reserved words for field names. Some nimrod had created a table with field
> names 'time' and 'date', boy, did that make trying to restore fun, fun,
> fun.....
>
> steve
--
Mark Dalphin email: mdalphin@amgen.com
Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
One Amgen Center Drive +1-805-375-0680 (home)
Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)
Michael S. Kelly writes:
> I've got the same problem with readline and psql using 7.0 RC1.
>
> I found that there was something odd when ran configure. Here's the
> readline stuff I grepped out of config.cache:
>
> ac_cv_header_readline_h=${ac_cv_header_readline_h='no'}
> ac_cv_header_readline_history_h=${ac_cv_header_readline_history_h='yes'}
> ac_cv_header_readline_readline_h=${ac_cv_header_readline_readline_h='yes'}
> ac_cv_lib_readline_main=${ac_cv_lib_readline_main='yes'}
> ac_cv_lib_readline_using_history=${ac_cv_lib_readline_using_history='yes'}
>
> Notice that the first line still says "no". Looks to me like it wants to
> find readline.h in /usr/include, as well as, /usr/include/readline. Could
> this be the source of the problem?
No, this is part of the solution. :) Across various versions of readline
the header files are either #include <readline.h> or #include
<readline/readline.h>, apparently for you the latter is the case.
I'm amazed that this won't enable readline support in psql. You can look
at src/include/config.h if the corresponding macros are defined
(HAVE_READLINE_READLINE_H and HAVE_LIBREADLINE). The other end of this is
src/bin/psql/input.[hc], perhaps you want to run the .c through the
preprocessor and see what happens. What readline version do you have? Did
it work in 6.5.*?
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden