Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Tom Lane wrote:
>> 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.
> But freed memory is clobbered, so if we were to have an assert that
> checks the node tag, it should show up. In fact, we do have such an
> assert, but only for compilers other than GCC, because the inline
> version of palloc() cannot have it for lack of infrastructure.
Well, but production installations don't have either memory clobbering
or Asserts, so fooling with that wouldn't have helped anyway. I suspect
what really happened here is that the bug was created by some late
change during 8.1 development, and nobody ever exercised the
anti-wraparound code path after that in an assert-enabled build :-(
In a non-assert build there's a fairly good chance that it'd still
work because the context header would still be there undamaged.
One thing we could try that would cost a lot less than de-inlining
palloc is to have MemoryContextDelete intentionally zero the methods
pointer. That still does nothing for the create-new-context-in-same-
spot issue, but at least it would catch palloc in a context that had
been deleted and not yet recycled.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
