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

Tom Lane wrote:
>"Oliver Elphick" <olly(at)lfix(dot)co(dot)uk> writes:
>> Using the cvs version updated this morning, this query kills the backend,
>> with no explanation in the log (-d 3):
>>
>> create table junk (id char(4) primary key, name text not 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 a complete update of the INDEX_MAX_KEYS changes?
>I committed the last of them about 1am EST (6am GMT) this morning, and
>it was a change to config.h.in ---- you would need to do a *full*
>configure, build, initdb cycle to be sure you have working code.

./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 backtrace of 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(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"For the LORD is good; his mercy is everlasting; and
his truth endureth to all generations."
Psalms 100:5