Thread: Re: [HACKERS] initdb problems
Bruce,
I've done a "cvs update" of my tree since your changes.
Firstly, configure.in seems to have reverted to it's original state
where the HAVE_LONG* stuff was broken.
I've fixed that in my source and run autoconf so that I could build.
Secondly the problem seems to be exactly the same as before.
"select * from pg_user" returns:-
template1=> select * from pg_user;
ERROR: Relation pg_user does not have attribute usename
Creating a table gives a core dump:-
template1=> create table dummy ( dummy int);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally before or while
processing the request.
We have lost the connection to the backend, so further processing is impossible.
Terminating.
[postgres@sparclinux pgsql]$
I'm currently building with "-g" so that I can take a look at what's
happening.
BTW: I've recently switched from cvsup to cvs and my local tree was
fetched afresh at the weekend. (have done several "cvs update"s since)
I'll let you know the results.
Keith.
Bruce Momjian <maillist@candle.pha.pa.us>
>
> Seems like there is some problem with cvs and people seeing all my
> changes, causing initdb problems.
>
> The only solution that has worked for two people is to re-download the
> entire cvs tree.
> Bruce, > > I've done a "cvs update" of my tree since your changes. > > Firstly, configure.in seems to have reverted to it's original state > where the HAVE_LONG* stuff was broken. > > I've fixed that in my source and run autoconf so that I could build. OK, I am not dealing with configure.in again on this int64 stuff. If someone wants to submit a patch to fix it, go ahead. No, "Just make it look like ...". > > Secondly the problem seems to be exactly the same as before. > > "select * from pg_user" returns:- > > template1=> select * from pg_user; > ERROR: Relation pg_user does not have attribute usename > > Creating a table gives a core dump:- See if pg_attribute has any empty attalign values, = ' '. > > template1=> create table dummy ( dummy int); > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally before or while > processing the request. > We have lost the connection to the backend, so further processing is impossible. > Terminating. > [postgres@sparclinux pgsql]$ > > I'm currently building with "-g" so that I can take a look at what's > happening. > > BTW: I've recently switched from cvsup to cvs and my local tree was > fetched afresh at the weekend. (have done several "cvs update"s since) > > I'll let you know the results. > > Keith. > > > Bruce Momjian <maillist@candle.pha.pa.us> > > > > Seems like there is some problem with cvs and people seeing all my > > changes, causing initdb problems. > > > > The only solution that has worked for two people is to re-download the > > entire cvs tree. > > -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> Firstly, configure.in seems to have reverted to it's original state
>> where the HAVE_LONG* stuff was broken.
> OK, I am not dealing with configure.in again on this int64 stuff. If
> someone wants to submit a patch to fix it, go ahead. No, "Just make it
> look like ...".
It's weird, I see the entries in "cvs log configure.in" saying that you
fixed it in updates 1.184 and 1.185, but there's no difference between
1.183 and 1.185:
$ cvs diff -r1.183 -r1.185 configure.in
Index: configure.in
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/configure.in,v
retrieving revision 1.183
retrieving revision 1.185
diff -r1.183 -r1.185
$
I hope this was just pilot error on your part, and not a symptom of
a cvs bug :-(
Anyway, here's a patch from the way that configure.in looks as of right
now, 1.185.
(It looks like the reason I messed up the int64 tests is that I copied
and pasted the HAVE_DBL_MIN_PROBLEM test, which was also broken...
fixed here.)
regards, tom lane
*** src/configure.in.orig Mon Aug 24 11:38:13 1998
--- src/configure.in Mon Aug 24 21:08:01 1998
***************
*** 522,528 ****
#endif
main() { double d = DBL_MIN; if (d != DBL_MIN) exit(-1); else exit(0); }],
AC_MSG_RESULT(yes),
! [AC_MSG_RESULT(no) AC_DEFINE(HAVE_DBL_MIN_PROBLEM)],
AC_MSG_RESULT(assuming ok on target machine))
dnl Check to see if we have a working 64-bit integer type.
--- 522,528 ----
#endif
main() { double d = DBL_MIN; if (d != DBL_MIN) exit(-1); else exit(0); }],
AC_MSG_RESULT(yes),
! [AC_DEFINE(HAVE_DBL_MIN_PROBLEM) AC_MSG_RESULT(no)],
AC_MSG_RESULT(assuming ok on target machine))
dnl Check to see if we have a working 64-bit integer type.
***************
*** 559,565 ****
main() {
exit(! does_int64_work());
}],
! [AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_INT_64)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))
--- 559,565 ----
main() {
exit(! does_int64_work());
}],
! [AC_DEFINE(HAVE_LONG_INT_64) AC_MSG_RESULT(yes)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))
***************
*** 596,602 ****
main() {
exit(! does_int64_work());
}],
! [AC_MSG_RESULT(yes) AC_DEFINE(HAVE_LONG_LONG_INT_64)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))
--- 596,602 ----
main() {
exit(! does_int64_work());
}],
! [AC_DEFINE(HAVE_LONG_LONG_INT_64) AC_MSG_RESULT(yes)],
AC_MSG_RESULT(no),
AC_MSG_RESULT(assuming not on target machine))
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > >> Firstly, configure.in seems to have reverted to it's original state > >> where the HAVE_LONG* stuff was broken. > > > OK, I am not dealing with configure.in again on this int64 stuff. If > > someone wants to submit a patch to fix it, go ahead. No, "Just make it > > look like ...". > > It's weird, I see the entries in "cvs log configure.in" saying that you > fixed it in updates 1.184 and 1.185, but there's no difference between > 1.183 and 1.185: > > $ cvs diff -r1.183 -r1.185 configure.in > Index: configure.in > =================================================================== > RCS file: /usr/local/cvsroot/pgsql/src/configure.in,v > retrieving revision 1.183 > retrieving revision 1.185 > diff -r1.183 -r1.185 > $ > > I hope this was just pilot error on your part, and not a symptom of > a cvs bug :-( > > Anyway, here's a patch from the way that configure.in looks as of right > now, 1.185. > > (It looks like the reason I messed up the int64 tests is that I copied > and pasted the HAVE_DBL_MIN_PROBLEM test, which was also broken... > fixed here.) > I think I applied a patch, then reversed it manually trying to fix the other section. Patch applied and config run. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
> I see the entries in "cvs log configure.in" saying that you
> fixed it in updates 1.184 and 1.185, but there's no difference between
> 1.183 and 1.185:
Are you using anonymous CVS, or CVSup? Also, have you done a full
checkout, or an update? If you haven't tried a full checkout, you
should; sometimes the tags seem to get messed up...
I haven't actually tried the tree recently, since I've got other
projects going which need a running system :/
- Tom