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