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
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? |
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 |