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