Re: [HACKERS] initdb problems
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] initdb problems |
Дата | |
Msg-id | 26105.904007952@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] initdb problems (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] initdb problems
|
Список | pgsql-hackers |
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))
В списке pgsql-hackers по дате отправления:
Следующее
От: "Thomas G. Lockhart"Дата:
Сообщение: Re: [GENERAL] More details on Database corruption