Re: [HACKERS] Buildfarm member gypsy_moth seems not to like alignment patch

2008-02-29 Thread Tom Lane
Jorgen Austvik - Sun Norway [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 This is unfortunate and surprising, since that patch was intended to
 prevent compilers from making unsafe alignment assumptions, but it sure
 looks like this compiler has instead added a new one.  Could you poke
 into it --- at least get a stack trace from the core dump?

 Running initdb with debug:

Hah, I guess the problem is that the compiler decided it was okay to put
the local variable chunk_data at an unaligned address.  Patched, but
we'll have to see whether any other places have similar issues.

Thanks for doing the gdb-work.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Buildfarm member gypsy_moth seems not to like alignment patch

2008-02-28 Thread Jorgen Austvik - Sun Norway

Tom Lane wrote:

This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one.  Could you poke
into it --- at least get a stack trace from the core dump?


Forgot some information about local variables:

(dbx) dump
toasttupDesc = 0xcf9538
chunk_size = 1996
t_values = ARRAY
toast_pointer = RECORD
chunk_seq = 1
rel = 0xcd8ff8
toastidx = 0xcf9858
toasttup = 0x8
toastrel = 0xcf9748
use_wal = '\001'
result = 0x1
data_p = 0xdbd354 
use_fsm = '\001'
data_todo = 2286
mycid = 10U
__func__ = toast_save_datum
t_isnull = ARRAY
value = 14406480U
chunk_data = RECORD
(dbx) print toast_pointer
toast_pointer = {
va_rawsize= 11963
va_extsize= 2286
va_valueid= 10953U
va_toastrelid = 2838U
}
(dbx) print t_values
t_values = (10953U, 0, 4290673827U)
(dbx) print t_isnull
t_isnull = 
(dbx) print chunk_data
chunk_data = {
hdr  = {
vl_len_ = 
vl_dat  = 
}
data = 
}

-J
--

Jørgen Austvik, Software Engineering - QA
Sun Microsystems Database Technology Group
begin:vcard
fn;quoted-printable:J=C3=B8rgen Austvik
n;quoted-printable:Austvik;J=C3=B8rgen
org:Sun Microsystems;Database Technology Group
adr:;;Haakon VII gt. 7b;Trondheim;;NO-7485;Norway
email;internet:[EMAIL PROTECTED]
title:Senior Engineer
tel;work:+47 73 84 21 10 
tel;fax:+47 73 84 21 01
tel;cell:+47 901 97 886
x-mozilla-html:FALSE
url:http://www.sun.com/
version:2.1
end:vcard


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] Buildfarm member gypsy_moth seems not to like alignment patch

2008-02-28 Thread Jorgen Austvik - Sun Norway

Tom Lane wrote:

It looks like gypsy_moth has been failing like this:

creating directory 
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data
 ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in 
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data/base/1
 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... Bus Error - core dumped
child process exited with exit code 138
initdb: data directory 
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data
 not removed at user's request

since I put in this patch:
http://archives.postgresql.org/pgsql-committers/2008-02/msg00270.php

This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one.  Could you poke
into it --- at least get a stack trace from the core dump?


Running initdb with debug:
--888888--
$./initdb -D /export/home/tmp/test -d -n
snip
DEBUG:  name: unnamed; blockState:   STARTED; state: INPROGR, 
xid/subid/cid: 0/1/35, nestlvl: 1, children: 

DEBUG:  commit transaction
DEBUG:  proc_exit(0)
DEBUG:  shmem_exit(0)
DEBUG:  exit(0)
ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... Bus Error - core dumped
child process exited with exit code 138
initdb: data directory /export/home/tmp/test not removed at user's request
--888888--

Stack trace:
--888888--
$ /opt/SUNWspro8/bin/dbx long_path/postgres core

program terminated by signal BUS (invalid address alignment)
Current function is toast_save_datum
 1171   SET_VARSIZE(chunk_data, chunk_size + VARHDRSZ);

(dbx) where 

=[1] toast_save_datum(rel = 0xcd8ff8, value = 14406480U, use_wal = 
\001', use_fsm = '\001'), line 1171 in tuptoaster.c
  [2] toast_insert_or_update(rel = 0xcd8ff8, newtup = 0xdba3e8, oldtup 
= (nil), use_wal = '\001', use_fsm = '\001'), line 700 in tuptoaster.c
  [3] heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8, cid = 10U, 
use_wal = '\001', use_fsm = '\001'), line 1815 in heapam.c
  [4] simple_heap_insert(relation = 0xcd8ff8, tup = 0xdba3e8), line 
1937 in heapam.c
  [5] InsertRule(rulname = 0xdaf730 _RETURN, evtype = 1, eventrel_oid 
= 10950U, evslot_index = -1, evinstead = '\001', event_qual = (nil), 
action = 0xdaf760, replace = '\0'), line 134 in rewriteDefine.c
  [6] DefineQueryRewrite(rulename = 0xdaf730 _RETURN, event_relid = 
10950U, event_qual = (nil), event_type = CMD_SELECT, is_instead = 
'\001', replace = '\0', action = 0xdaf760), line 461 in rewriteDefine.c
  [7] DefineViewRules(viewOid = 10950U, viewParse = 0xdab070, replace = 
'\0'), line 275 in view.c
  [8] DefineView(stmt = 0xd3f920, queryString = 0xd9b888 /*\n * 
PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL 
Global Development Group\n *\n * $PostgreSQL: 
pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 
tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \nSELECT \n 
rolname,\nrolsuper,\nrolinherit,\n 
rolcreaterole,\nrolcreatedb,\nrolcatupdate,\n 
rolcanlogin,\nrolconnlimit,\n''::text as 
rolpassword,\nrolvaliduntil,\nrolconfig,\noid\n 
   FROM pg_aut ...), line 447 in view.c
  [9] ProcessUtility(parsetree = 0xd3f920, queryString = 0xd9b888 /*\n 
* PostgreSQL System Views\n *\n * Copyright (c) 1996-2008, PostgreSQL 
Global Development Group\n *\n * $PostgreSQL: 
pgsql/src/backend/catalog/system_views.sql,v 1.47 2007/10/22 20:13:37 
tgl Exp $\n */\n\nCREATE VIEW pg_roles AS \nSELECT \n 
rolname,\nrolsuper,\nrolinherit,\n 
rolcreaterole,\nrolcreatedb,\nrolcatupdate,\n 
rolcanlogin,\nrolconnlimit,\n''::text as 
rolpassword,\nrolvaliduntil,\nrolconfig,\noid\n 
   FROM pg_aut ..., params = (nil), isTopLevel = '\0', dest = 
0xbb1534, completionTag = 0xffbef64c ), line 894 in utility.c
  [10] PortalRunUtility(portal = 0xd39e68, utilityStmt = 0xd3f920, 
isTopLevel = '\0', dest = 0xbb1534, completionTag = 0xffbef64c ), line 
1178 in pquery.c
  [11] PortalRunMulti(portal = 0xd39e68, isTopLevel = '\0', dest = 
0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c ), line 1266 
in pquery.c
  [12] PortalRun(portal = 0xd39e68, count = 2147483647, isTopLevel = 
'\0', dest = 0xbb1534, altdest = 0xbb1534, completionTag = 0xffbef64c 
), line 814 in pquery.c
  [13] exec_simple_query(query_string = 0xd2fe38 /*\n * PostgreSQL 
System Views\n 

[HACKERS] Buildfarm member gypsy_moth seems not to like alignment patch

2008-02-27 Thread Tom Lane
It looks like gypsy_moth has been failing like this:

creating directory 
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data
 ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating configuration files ... ok
creating template1 database in 
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data/base/1
 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... Bus Error - core dumped
child process exited with exit code 138
initdb: data directory 
/export/home/tmp/pg-test/build-suncc/HEAD/pgsql.21325/src/test/regress/./tmp_check/data
 not removed at user's request

since I put in this patch:
http://archives.postgresql.org/pgsql-committers/2008-02/msg00270.php

This is unfortunate and surprising, since that patch was intended to
prevent compilers from making unsafe alignment assumptions, but it sure
looks like this compiler has instead added a new one.  Could you poke
into it --- at least get a stack trace from the core dump?

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings