> From: Tom Lane <tgl@sss.pgh.pa.us>
>
> Karl DeBisschop <kdebisschop@range.infoplease.com> writes:
> > The problem manifests itself as
>
> > webusers=> CREATE INDEX zdaily_id ON daily (id);
> > pqReadData() -- backend closed the channel unexpectedly.
> > This probably means the backend terminated abnormally
> > before or while processing the request.
>
> Is a corefile dumped in the database directory when this happens?
> If so, can you get a backtrace from it with gdb?
>
> > This did work for us using 6.5.1 compiled in house. Our problems
> > started with the 6.5.3 RPM.
>
> Hmm. We have been seeing some reports recently of other odd behavior
> with the Linux RPMs (see the "ordering RH6.1" thread on pgsql-hackers).
> Would you take the time to compile 6.5.3 from source and see if you
> still see the same behavior?
>
> If you do this, please compile the backend with full debug+assert
> support, which is to say
> (a) add --enable-cassert to the configure command;
> (b) do make COPT=-g all instead of just make all.
> That should make the gdb backtrace a lot more informative, if
> a coredump happens...
Finally got a tiny little error message:
sterno.infoplease.com:/u/kdebisschop> psql -p 5433 webusers -c "CREATE INDEX zdaily_id ON daily (id)"
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.
[2]+ Done psql -p 5433 webusers -c "CREATE INDEX zdaily_date_n ON daily (date,n)"
sterno.infoplease.com:/u/kdebisschop> psql -p 5433 webusers -c "CREATE INDEX zdaily_id ON daily USING hash (id)"
ERROR: cannot open segment 1 of relation zdaily_id
sterno.infoplease.com:/u/kdebisschop>
Still no core dump. Each of these takes an hour or so to croak.
Any ideas would be welcome.
Karl DeBisschop
