Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11) - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)
Date
Msg-id 87ocy5ddh3.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Simon Riggs <simon@2ndQuadrant.com> writes:
>> Can we add something to memory contexts to make this fail every time?
>
> No, not really.  AFAICS the reason for Alvaro not seeing it must be that
> on his machine the new transaction happens to allocate its
> TopTransactionContext control block right in the same place where the
> old one was.
>
> We could have a debugging mode in which pfree'd space is never recycled
> for reuse (just filled with 0xdeadbeef or whatever and left to sit).

Hm, I wonder how much more practical it would be if we recycled it but offset
the pointer by maxalign. We would waste 4/8 bytes per palloc/free cycle
instead of the whole chunk.

(Whether palloc could actually do this would be another question, there are
lots of allocator algorithms that wouldn't be able to, I think.)

If we had a more formalized save_memory_context()/restore_memory_context()
which gave you more than just a pointer we could do better for this particular
case. save_memory_context() could hand you a struct with a pointer as well as
some sanity check values about the context you're saving.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)
Next
From: Tom Lane
Date:
Subject: Re: pg_dump versus views and opclasses