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 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.Elphick@lfix.co.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