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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
