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

*punting to PostGIS folks for a look*

--
Craig Ringer

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