Thread: BUG #5977: Crash on delete
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";
"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
=?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