On 2014-04-18 16:44:55 +0200, Robert Haas wrote: > On Thu, Apr 17, 2014 at 10:47 PM, Andres Freund <and...@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?
Not precicisely sure what you mean, but the only memory allocation in HeapTupleHeaderGetCmax() and log_heap_new_cid() is that Assert(). And that's the only "forbidden" thing in that codepath. Now, we could alternatively restructure the codepaths so they pass in xmax from outside the critical section, but I had a quick look and the risk/complications from that seems bigger than the assertion buys us there. I don't have a better idea unfortunately :( 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
