Re: Postgres 9.0 crash on win7

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 *(at)#$@#$(at)$* thing
though. Ideas?

*punting to PostGIS folks for a look*

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/