Re: assertion in 9.4 with wal_level=logical

On 2014-04-18 11:50:55 -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > > 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.

Since nobody seemed to have a better idea I've proceeded in doing
so... Not pretty.
I've verified that the assertion could be triggered before, but not
after by doing something like:
S1:
CREATE TABLE a();
BEGIN;
SELECT * FROM pg_class WHERE relname = 'a' FOR SHARE;

S2:
BEGIN;
SELECT * FROM pg_class WHERE relname = 'a' FOR SHARE;
COMMIT;

S1:
ALTER TABLE a RENAME to b;
ALTER TABLE b RENAME to a; -- this triggered the assertion

That seems a tad too obscure for its own isolationtester test.

Thanks for the report, Steve!

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services