MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)
Date: 2009-01-17 08:54:38
Message-ID: 1232182478.31669.182.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


On Fri, 2009-01-16 at 18:43 -0500, 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.

Can we add something to memory contexts to make this fail every time?

Seems like we should be able to detect this class of error. If we can't
it seems likely that a number of similar cases exist with other
contexts.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2009-01-17 11:26:21 Re: Autovacuum daemon terminated by signal 11
Previous Message Scott Marlowe 2009-01-17 08:08:52 Re: Trigger to clone across databases?

Browse pgsql-hackers by date

  From Date Subject
Next Message Alan Li 2009-01-17 09:44:07 Fixes for compiler warnings
Previous Message KaiGai Kohei 2009-01-17 04:21:46 Status Report on SE-PostgreSQL