Robert Haas wrote:
> On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-04-17 17:40:01 -0300, Alvaro Herrera wrote:
> >> For once, this looks more like a problem in logical decoding, which is
> >> trying to assert about the tuple being updated; the assertion failing is
> >> the one added a week ago about not palloc'ing in a critical section.
> >
> > It's this (older) assertion in HeapTupleHeaderGetCmax():
> >
> > Assert(TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetUpdateXid(tup)));
> >
> > That can allocate memory if xmax is a multixact... Does anybody have a
> > better idea to solve this than adding a CritSectionCount == 0 && in
> > there?
>
> Blech. Isn't that just nerfing the assertion?
Well, that's exactly the point. Most of the time,
HeapTupleHeaderGetCmax gets called in a non-critical section, and we
want to run the assertion in that case. But it's not huge trouble if
the assertion is not run in the rare case where HeapTupleHeaderGetCmax
is being used to write a Xlog record.
It's a bit painful that HeapTupleHeaderGetUpdateXid allocates memory,
but to fix that we would have to remove all allocations from
GetMultiXactIdMembers which doesn't sound feasible.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
