Re: [HACKERS] CREATE TABLE ... PRIMARY KEY kills backend

Tom Lane wrote: >"Oliver Elphick" <olly@lfix.co.uk> writes: >> Using the cvs version updated this morning, this query
killsthe backend, >> with no explanation in the log (-d 3): >> >>   create table junk (id char(4) primary key, name
textnot null) > >Works for me: > >regression=# create table junk (id char(4) primary key, name text not null); >NOTICE:
CREATE TABLE/PRIMARY KEY will create implicit index 'junk_pkey' for     > table 'junk' >CREATE > >Are you sure you have
acomplete update of the INDEX_MAX_KEYS changes? >I committed the last of them about 1am EST (6am GMT) this morning, and
>itwas a change to config.h.in ---- you would need to do a *full* >configure, build, initdb cycle to be sure you have
workingcode. 
 
./configure --with-tcl --with-mb=UNICODE --with-odbc --enable-locale 
--with-maxbackends=64 --with-pgport=5431 --program-prefix=pg7.

(The program-prefix doesn't seem to do anything.)

Database destoyed and initdb run...
 >If that doesn't do it for you, there may be a platform-dependent bug >still lurking; can you provide a debugger
backtraceof the crashed >backend?
 

Segmentation fault (in the end):
#0  0x400f068d in _IO_default_xsputn () from /lib/libc.so.6
#1  0x400e0126 in vfprintf () from /lib/libc.so.6
#2  0x400edf23 in vsnprintf () from /lib/libc.so.6
#3  0x80a8e82 in appendStringInfo ()
#4  0x80c244d in _outTypeName ()
#5  0x80c43da in _outNode ()
#6  0x80c2391 in _outColumnDef ()
... 
#157128 0x80c23f6 in _outColumnDef ()
#157129 0x80c43ca in _outNode ()
#157130 0x80c407c in _outNode ()
#157131 0x80c3f7a in _outConstraint ()
#157132 0x80c475a in _outNode ()
#157133 0x80c407c in _outNode ()
#157134 0x80c23f6 in _outColumnDef ()
#157135 0x80c43ca in _outNode ()
#157136 0x80c407c in _outNode ()
#157137 0x80c219c in _outCreateStmt ()
#157138 0x80c43aa in _outNode ()
#157139 0x80c2578 in _outQuery ()
#157140 0x80c43fa in _outNode ()
#157141 0x80c47fd in nodeToString ()
#157142 0x80ed791 in pg_parse_and_plan ()
#157143 0x80eda46 in pg_exec_query_dest ()
#157144 0x80eda01 in pg_exec_query ()
#157145 0x80eeb82 in PostgresMain ()
#157146 0x80d7ee7 in DoBackend ()
#157147 0x80d7abe in BackendStartup ()
#157148 0x80d6cc9 in ServerLoop ()
#157149 0x80d66ae in PostmasterMain ()
#157150 0x80ae2cb in main ()
#157151 0x400bc7e2 in __libc_start_main () from /lib/libc.so.6

I don't have any line number info, so I'll have to rebuild in order to
do more detailed tracing.
 >I'd also suggest running the regress tests ... they pass here, with >the exception of the 'array' test ...

The regression test doesn't seem to work at all with multibyte enabled:

=============== creating new regression database...   =================
createdb: "UNICODE" is not a valid encoding name.
createdb failed
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILE regress.out

The reason is that regress.sh uses createdb; createdb has a bad test for
the encoding value (I have sent a patch separately).  So I assume no-one
has run regression tests with multibyte-encoding enabled?

I fixed the createdb bug and ran the regression test.  The constraints
test failed when trying to create a table with a primary key.  Every
test thereafter failed immediately [pqReadData() -- backend closed the
channel unexpectedly]; it appears that the primary key error messes up
the postmaster in some way.


-- 
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver              PGP key from public servers; key
ID32B8FAA1                ========================================    "For the LORD is good; his mercy is everlasting;
and     his truth endureth to all generations."                                             Psalms 100:5