initdb problems
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,
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>
Show quoted text
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.
Import Notes
Resolved by subject fallback
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 usenameCreating 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))Import Notes
Reply to msg id not found: YourmessageofMon24Aug1998180320-0400199808242203.SAA07109@candle.pha.pa.us | Resolved by subject fallback
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
Hi All,
My problems seem to be getting worse!!
Yesterday I was only getting a crash when I tried to create a table.
Today, with the latest from cvs I'm getting a crash on a simple select.
Here's the backtrace:-
Program received signal SIGSEGV, Segmentation fault.
0x95564 in transformTargetList (pstate=0x15c790, targetlist=0x15ec10)
at parse_target.c:583
583 attrname =
strVal(lfirst(att->attrs));
(gdb) bt
#0 0x95564 in transformTargetList (pstate=0x15c790, targetlist=0x15ec10)
at parse_target.c:583
#1 0x885f4 in transformSelectStmt (pstate=0x15c790, stmt=0x15c7d0) at
analyze.c:867
#2 0x877a8 in transformStmt (pstate=0x15c790, parseTree=0x15c7d0) at
analyze.c:190
#3 0x87504 in parse_analyze (pl=0x15eb50, parentParseState=0x0) at analyze.c:76
#4 0x8e8fc in parser (str=0x0, typev=0x0, nargs=0) at parser.c:64
#5 0xaef60 in pg_parse_and_plan (
query_string=0xefffd1a0 " select * from pg_class;", typev=0x0, nargs=0,
queryListP=0xefffd0bc, dest=Remote, aclOverride=0 '\000') at postgres.c:402
#6 0xaf420 in pg_exec_query_dest (
query_string=0xefffd1a0 " select * from pg_class;", dest=Remote,
aclOverride=0 '\000') at postgres.c:668
#7 0xaf3d4 in pg_exec_query (query_string=0xefffd1a0 " select * from
pg_class;")
at postgres.c:643
#8 0xb0388 in PostgresMain (argc=1169408, argv=0xeffff1a0, real_argc=10,
real_argv=0xeffffd84) at postgres.c:1480
#9 0x98f7c in DoBackend (port=0xff400) at postmaster.c:1412
#10 0x989b8 in BackendStartup (port=0x15fc00) at postmaster.c:1191
#11 0x97fe4 in ServerLoop () at postmaster.c:725
#12 0x97b3c in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:534
#13 0x6c30c in main (argc=10, argv=0xeffffd84) at main.c:93
For info, each time I do a cvs update and then copy the entire tree to
another machine. The target directory on the other machine is an empty
/usr/local/pgsql.
I then do a configure/make/make install/initdb before commencing
any testing.
I'm starting to get worried about my hardware/OS as no-one else
seems to be reporting similar problems.
For reference.
SPARC/Linux (Redhat 4.2) running on a SPARCstation IPC.
Is anyone else trying to build the latest source on any SPARC
hardware with any OS? (Solaris,SunOS)
Keith.
Bruce Momjian <maillist@candle.pha.pa.us>
Show quoted text
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.
Import Notes
Resolved by subject fallback
I am applying a patch now. I also got your message about the
alignments. They should be 'd' as you said. Seems like the bootstrap
has it wrong, as it defaults to 'i' for things it could not figure out.
Didn't matter before, but multi-key indexes require them to be correct.
Should have something tomorrow.
Hi All,
My problems seem to be getting worse!!
Yesterday I was only getting a crash when I tried to create a table.
Today, with the latest from cvs I'm getting a crash on a simple select.
Here's the backtrace:-
Program received signal SIGSEGV, Segmentation fault.
0x95564 in transformTargetList (pstate=0x15c790, targetlist=0x15ec10)
at parse_target.c:583
583 attrname =
strVal(lfirst(att->attrs));
(gdb) bt
#0 0x95564 in transformTargetList (pstate=0x15c790, targetlist=0x15ec10)
at parse_target.c:583
#1 0x885f4 in transformSelectStmt (pstate=0x15c790, stmt=0x15c7d0) at
analyze.c:867
#2 0x877a8 in transformStmt (pstate=0x15c790, parseTree=0x15c7d0) at
analyze.c:190
#3 0x87504 in parse_analyze (pl=0x15eb50, parentParseState=0x0) at analyze.c:76
#4 0x8e8fc in parser (str=0x0, typev=0x0, nargs=0) at parser.c:64
#5 0xaef60 in pg_parse_and_plan (
query_string=0xefffd1a0 " select * from pg_class;", typev=0x0, nargs=0,
queryListP=0xefffd0bc, dest=Remote, aclOverride=0 '\000') at postgres.c:402
#6 0xaf420 in pg_exec_query_dest (
query_string=0xefffd1a0 " select * from pg_class;", dest=Remote,
aclOverride=0 '\000') at postgres.c:668
#7 0xaf3d4 in pg_exec_query (query_string=0xefffd1a0 " select * from
pg_class;")
at postgres.c:643
#8 0xb0388 in PostgresMain (argc=1169408, argv=0xeffff1a0, real_argc=10,
real_argv=0xeffffd84) at postgres.c:1480
#9 0x98f7c in DoBackend (port=0xff400) at postmaster.c:1412
#10 0x989b8 in BackendStartup (port=0x15fc00) at postmaster.c:1191
#11 0x97fe4 in ServerLoop () at postmaster.c:725
#12 0x97b3c in PostmasterMain (argc=0, argv=0xeffffd84) at postmaster.c:534
#13 0x6c30c in main (argc=10, argv=0xeffffd84) at main.c:93For info, each time I do a cvs update and then copy the entire tree to
another machine. The target directory on the other machine is an empty
/usr/local/pgsql.I then do a configure/make/make install/initdb before commencing
any testing.I'm starting to get worried about my hardware/OS as no-one else
seems to be reporting similar problems.For reference.
SPARC/Linux (Redhat 4.2) running on a SPARCstation IPC.
Is anyone else trying to build the latest source on any SPARC
hardware with any OS? (Solaris,SunOS)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)Hi All,
My problems seem to be getting worse!!
Yesterday I was only getting a crash when I tried to create a table.
Today, with the latest from cvs I'm getting a crash on a simple select.
Here's the backtrace:-
OK, selects should be fixed now. Also:
select relname, attname,attalign from pg_class, pg_attribute, pg_type
where atttypid = pg_type.oid and typname = 'name' and pg_class.oid =
attrelid and attalign != 'd'
now returns no rows, as it should. Some tricky work, but they are all
correct now. Let's see if that fixes the Sparc problem.
--
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>
Hi All,
My problems seem to be getting worse!!
Yesterday I was only getting a crash when I tried to create a table.
Today, with the latest from cvs I'm getting a crash on a simple select.
Here's the backtrace:-
OK, selects should be fixed now. Also
Confirmed, selects are fine, thanks.
select relname, attname,attalign from pg_class, pg_attribute, pg_type
where atttypid = pg_type.oid and typname = 'name' and pg_class.oid =
attrelid and attalign != 'd'now returns no rows, as it should. Some tricky work, but they are all
correct now. Let's see if that fixes the Sparc problem.
Unfortunately not but... I'm seeing some strange things in gdb.
(apologies again for the wide post :-( )
Attaching to program `/usr/local/pgsql/bin/postmaster', process 5422
Reading symbols from /lib/libdl.so.1.8.3...done.
Reading symbols from /lib/libm.so.5.0.6...done.
Reading symbols from /usr/lib/libreadline.so.2.0...done.
Reading symbols from /lib/libtermcap.so.2.0.8...done.
Reading symbols from /usr/lib/libncurses.so.3.0...done.
Reading symbols from /lib/libc.so.5.3.12...done.
Reading symbols from /lib/ld-linux.so.1...done.
0xe00f59c4 in __read ()
(gdb) break DataFill
Breakpoint 1 at 0x26b34: file heaptuple.c, line 126.
(gdb) cont
Continuing.
Breakpoint 1, DataFill (data=0x1b8438 "", tupleDesc=0x160e30, value=0xefffcdf8,
nulls=0xefffce48 ' ' <repeats 16 times>, "à\034 ", infomask=0x1b8430,
bit=0x0) at heaptuple.c:126
126 bits8 *bitP = 0;
(gdb)
Continuing.
Breakpoint 1, DataFill (data=0x1b1318 "", tupleDesc=0x160a70, value=0xefffccdc,
nulls=0xefffcce0 " \026\0160",
infomask=0xefffca66, bit=0x0) at heaptuple.c:126
126 bits8 *bitP = 0;
(gdb)
Continuing.
Breakpoint 1, DataFill (data=0x160618 "", tupleDesc=0x1607b0, value=0xefffccdc,
nulls=0xefffcce0 " \026\0160",
infomask=0xefffca66, bit=0x0) at heaptuple.c:126
126 bits8 *bitP = 0;
(gdb)
Continuing.
Breakpoint 1, DataFill (data=0x1b1220 "", tupleDesc=0x160610, value=0xefffce14,
nulls=0xefffce18 "",
infomask=0xefffcb9e, bit=0x1b1218 "") at heaptuple.c:126
126 bits8 *bitP = 0;
(gdb) step
130 int numberOfAttributes = tupleDesc->natts;
(gdb)
127 int bitmask = 0;
(gdb)
133 if (bit != NULL)
(gdb)
135 bitP = &bit[-1];
(gdb)
136 bitmask = CSIGNBIT;
(gdb)
141 for (i = 0; i < numberOfAttributes; i++)
(gdb)
143 if (bit != NULL)
(gdb)
145 if (bitmask != CSIGNBIT)
(gdb)
149 bitP += 1;
(gdb)
150 *bitP = 0x0;
(gdb)
151 bitmask = 1;
(gdb)
154 if (nulls[i] == 'n')
(gdb)
160 *bitP |= bitmask;
(gdb)
163 switch (att[i]->attlen)
(gdb) print att[i]->attlen
$1 = 4
(gdb) step
189 *(int32 *) data = (att[i]->attbyval ?
(gdb)
193 break;
(gdb)
141 for (i = 0; i < numberOfAttributes; i++)
(gdb)
143 if (bit != NULL)
(gdb)
145 if (bitmask != CSIGNBIT)
(gdb)
154 if (nulls[i] == 'n')
(gdb)
160 *bitP |= bitmask;
(gdb)
163 switch (att[i]->attlen)
(gdb)
195 if (att[i]->attlen < sizeof(int32))
(gdb) print att[i]->attlen
$2 = 32
(gdb) step
198 if (att[i]->attalign == 'd')
(gdb)
200 data = (char *)
DOUBLEALIGN(data);
(gdb)
201 memmove(data,
DatumGetPointer(value[i]),
(gdb)
204 }
(gdb)
208 memmove(data,
DatumGetPointer(value[i]),
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0xe016e6b4 in _wordcopy_fwd_aligned ()
So the memmove() at line 201 gets executed OK, no SIGSEGV but how do we get
to line 208 and call the memmove() again!!
I'm sure I must be missing the obvious but...
194 default:
195 if (att[i]->attlen < sizeof(int32))
196 elog(ERROR, "DataFill: attribute
%d has len %d",
197 i, att[i]->attlen);
198 if (att[i]->attalign == 'd')
199 {
200 data = (char *)
DOUBLEALIGN(data);
201 memmove(data,
DatumGetPointer(value[i]),
202 att[i]->attlen);
203 data += att[i]->attlen;
204 }
205 else
206 {
207 data = (char *) LONGALIGN(data);
208 memmove(data,
DatumGetPointer(value[i]),
209 att[i]->attlen);
210 data += att[i]->attlen;
211 }
212 break;
Help,
Keith.
Import Notes
Resolved by subject fallback
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
Bruce Momjian <maillist@candle.pha.pa.us>
Hi All,
My problems seem to be getting worse!!
Yesterday I was only getting a crash when I tried to create a table.
Today, with the latest from cvs I'm getting a crash on a simple select.
Here's the backtrace:-
OK, selects should be fixed now. Also
Confirmed, selects are fine, thanks.
select relname, attname,attalign from pg_class, pg_attribute, pg_type
where atttypid = pg_type.oid and typname = 'name' and pg_class.oid =
attrelid and attalign != 'd'now returns no rows, as it should. Some tricky work, but they are all
correct now. Let's see if that fixes the Sparc problem.Unfortunately not but... I'm seeing some strange things in gdb.
(apologies again for the wide post :-( )
I just fixed some more alignment problems in the catalogs. Sorry.
Please try again.
--
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)