Tom Lane wrote:
> Hmm. This isn't very trustworthy for lack of debug symbols (what we're
> probably looking at are the nearest global function names before the
> actual locations). However, it strongly suggests that something is
> broken in the active memory context, and the most likely explanations
> for that are either a memory clobber (eg overrunning the requested size
> of a chunk) or CurrentMemoryContext pointing at a context that was
> already freed. The latter theory ties into the fact that it seems to be
> happening during transaction end. But any such bug of either type
> should have been found years ago given that development is invariably
> done with CLOBBER_FREED_MEMORY enabled.
>
> Alvaro, any thoughts? Remember this is 8.1.15.
Not really. It seems like this must be happening on the vicinity of
process_whole_db(), which is a less used code path than do_autovacuum(),
so it's more likely to have bugs. I don't see anything obviously wrong
though.
I note that process_whole_db is not changing to AutovacMemCxt the way
do_autovacuum() does, but I don't see any way that this could cause a
problem.
Hmm, vacuum() creates a new memory context under PortalContext, but I
don't see that one set anywhere on the autovacuum path ... is that
bogus?
The lack of debug symbols makes this all mere guesses though. The
backtrace did not make a lot of sense to me.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support