"Oliver Elphick" <olly@lfix.co.uk> writes:
> 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 () ^^^^^^
Hmm, I take it this is a stack-growth-limit-exceeded failure, although
your system isn't reporting it that way.
This is a known bug that's been there for quite a while: PRIMARY KEY
generates a parse tree with circular references, so if you have parse
tree dumping turned on, you get an infinite recursion in the dumper
code. It needs to be fixed, but hasn't gotten to the top of anyone's
to-do list (and a clean way to fix it isn't obvious).
> I fixed the createdb bug and ran the regression test. The constraints
> test failed when trying to create a table with a primary key.
If you had -d set high enough, it would...
> 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.
The WAL postmaster takes a few seconds to recover before it will allow
new connections (I have a proposal on the table that it should just
delay accepting the connections, instead of rejecting 'em, but there
hasn't been any discussion about that). I usually see that the next
three or four regression tests fail after a crash, but if your machine
is fast enough it might be that they all do.
I have noticed that recent versions of libpq fail to display the
connection-refused error message that I assume the postmaster is
returning. That useta work ... someone broke it ...
regards, tom lane