Just an update on this issue:
I've been able to reproduce the crash (thanks for the test case!) and
obtain the crash information here on my 32-bit windows 7 install, so
there's no need for you to do anything else so far.
I still can't get a usable backtrace. The autovacuum workers/launcher
split makes it *really* hard to catch an autovacuum worker in action.
The post-mortem debugger won't trigger for service processes, so I can't
trap it that way, and I can't pre-attach a debugger to it.
OTOH, it's now pretty clearly autovacuum that's dying, as Tom Lane
suggested it probably would be.
debug5 logging shows:
2010-10-04 18:18:54 WST 3692 DEBUG: InitPostgres
2010-10-04 18:18:54 WST 3692 DEBUG: my backend id is 3
2010-10-04 18:18:54 WST 3692 DEBUG: StartTransaction
2010-10-04 18:18:54 WST 3692 DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-10-04 18:18:54 WST 3692 DEBUG: mapped win32 error code 2 to 2
2010-10-04 18:18:54 WST 3692 DEBUG: CommitTransaction
2010-10-04 18:18:54 WST 3692 DEBUG: name: unnamed; blockState: STARTED;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-10-04 18:18:54 WST 3692 DEBUG: autovacuum: processing database "test"
2010-10-04 18:18:54 WST 3692 DEBUG: StartTransaction
2010-10-04 18:18:54 WST 3692 DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-10-04 18:18:54 WST 3692 DEBUG: pg_statistic: vac: 0 (threshold 118), anl:
0 (threshold 84)
... followed by lots more startup messages, a series of transactions, then:
2010-10-04 18:18:55 WST 3692 DEBUG: name: unnamed; blockState: STARTED;
state: INPROGR, xid/subid/cid: 159661/1/0 (used), nestlvl: 1, children:
2010-10-04 18:18:55 WST 3692 DEBUG: StartTransaction
2010-10-04 18:18:55 WST 3692 DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-10-04 18:18:55 WST 3692 DEBUG: poslist: vac: 0 (threshold 50), anl: 1804
(threshold 50)
2010-10-04 18:18:55 WST 3692 DEBUG: autovac_balance_cost(pid=3692 db=98315,
rel=98390, cost_limit=200, cost_delay=20)
2010-10-04 18:18:55 WST 3692 DEBUG: CommitTransaction
2010-10-04 18:18:55 WST 3692 DEBUG: name: unnamed; blockState: STARTED;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-10-04 18:18:55 WST 3692 DEBUG: StartTransaction
2010-10-04 18:18:55 WST 3692 DEBUG: name: unnamed; blockState: DEFAULT;
state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
2010-10-04 18:18:55 WST 3692 DEBUG: analyzing "public.poslist"
2010-10-04 18:18:55 WST 2408 DEBUG: server process (PID 3692) was terminated
by exception 0xC0000005
2010-10-04 18:18:55 WST 2408 LOG: server process (PID 3692) was terminated by
exception 0xC0000005
Autovacuum usually dies after:
analyzing "public.suolo" (three times)
but I've also seen it die after:
analyzing "public.poslist"
as shown above.
I'm really struggling to get a debugger attached to the *...@#$@#...@$* thing
though. Ideas?
*punting to PostGIS folks for a look*
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
