Re: Autovacuum daemon terminated by signal 11 - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: Autovacuum daemon terminated by signal 11
Date
Msg-id 20090117041433.GI12449@alvh.no-ip.org
Whole thread Raw
In response to Re: Autovacuum daemon terminated by signal 11  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Autovacuum daemon terminated by signal 11
List pgsql-general
Tom Lane wrote:

> What is happening is that autovacuum_do_vac_analyze contains
>
>     old_cxt = MemoryContextSwitchTo(AutovacMemCxt);
>     ...
>     vacuum(vacstmt, relids);
>     ...
>     MemoryContextSwitchTo(old_cxt);
>
> and at the time it is called by process_whole_db, CurrentMemoryContext
> points at TopTransactionContext.  Which gets destroyed because vacuum()
> internally finishes that transaction and starts a new one.  When we
> come out of vacuum(), CurrentMemoryContext again points at
> TopTransactionContext, but *its not the same one*.  The closing
> MemoryContextSwitchTo is installing a stale pointer, which then remains
> active into CommitTransaction.  It's a wonder this code ever works.

Hmm, in retrospect this is pretty obviously buggy.  I can't say that
it's that easy for me to reproduce it though; I definitely can't make it
crash.  Maybe by sheer luck, the new TopTransactionContext pointer
points to the same memory area that the old was stored in.

I think this patch should fix it.  Justin, would you try it and report
back?  I would commit it right away since it seems simple enough, but
since I can't reproduce the crash, I prefer external confirmation first
:-)

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment

pgsql-general by date:

Previous
From: Leif Jensen
Date:
Subject: Re: Slave server: FATAL: incorrect checksum in control file
Next
From: Vincent Predoehl
Date:
Subject: accessing user table structures from SQL