Thread: BUG #5977: Crash on delete

BUG #5977: Crash on delete

From
"Anton Kuznetsov"
Date:
The following bug has been logged online:

Bug reference:      5977
Logged by:          Anton Kuznetsov
Email address:      antosha86@mail.ru
PostgreSQL version: 8.3.1
Operating system:   Linux 2.4.32
Description:        Crash on delete
Details:

Server crases on delete and than automatically restarts;
Log message was:

TRAP: FailesAssertion("!(outerstartsel <= outerendsel)",  File:
"costsize.c", String: 1540)
Log: Server process (PID 11785) was terminated by signal 6: Aborted;
Log: Shutting down other active server processes
Warning: Closing connection due to shutdown of other server process.
The postmaster has command this process to rollback the current transaction
and exit, because other server process exited abnormally and possibly
corrupted shared memory.
In a moment you should be able to reconnect to the database and repeat your
command.

...And so on for each process.

All server processes stoped... restarting;
Database system was interrupted; last known up at 2011-04-13 11:33:57 MSD;
Database system shutdown abnormally; automatic recovery;
REDO begin from 1/F168073C
record with zero length in 1/F27055AC
REDO end in 1/F2705580
last completed transaction transaction was at log time 2011-04-13
11:34:36.383714+04
autovacuum launcher started
database system is ready to accept connection

Delete query not appeared in log file (query log enabled)

Using hibernate 3.0 to work with database;
and Slony1-1.2.14-1.i486 to manage replication.
Delete is not working with only one table, but with all records (prevuously
added or new ones);
Things i allready try;
dump database;
create new one with same structure (and without replication);
restore only table data from dump to new database;
run "vacuum full analayze" and "reindex database";

Re: BUG #5977: Crash on delete

From
Tom Lane
Date:
"Anton Kuznetsov" <antosha86@mail.ru> writes:
> Server crases on delete and than automatically restarts;
> Log message was:

> TRAP: FailesAssertion("!(outerstartsel <= outerendsel)",  File:
> "costsize.c", String: 1540)

That's pretty interesting ... can you put together a self-contained test
case?  That might be a bit difficult because this is probably dependent
on data statistics.  But it should at least be possible to determine
which join clause is causing the problem, and then show us the pg_stats
entries for the columns used in the join.  This isn't going to be
dependent on whether the command is a DELETE or not, just the table join
conditions.

            regards, tom lane

Re: Re[2]: BUG #5977: Crash on delete

From
Tom Lane
Date:
=?utf-8?Q?=D0=90=D0=BD=D1=82=D0=BE=D0=BD_=D0=9A=D1=83=D0=B7=D0=BD=D0=B5=D1=86=D0=BE=D0=B2?= <antosha86@mail.ru> writes:
> TRAP: FailesAssertion("!(outerstartsel <= outerendsel)",  File:
> "costsize.c", String: 1540)

On reflection it seems the only way you could get past the preceding
"Assert(outer_skip_rows <= outer_rows)" and then crash there would be
if outer_path_rows was NaN, which would result in both outerstartsel and
outerendsel becoming NaN, and then the comparison would fail to yield
true.

(A negative value of outer_path_rows would do it too, but that case has
been excluded at the top of the function.)

So the actual bug is presumably that some other piece of the planner is
returning NaN instead of a valid rowcount estimate.  Unfortunately,
there are a whole lot of places to look, and not nearly enough
information here to narrow it down ...

            regards, tom lane