On Tue, 2010-04-27 at 16:18 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
> >> WTF?  Either the comment is wrong or this should not be an elog
> >> condition.
> 
> > That section of code has been rewritten many times. I think it is now
> > inaccurate and should be removed. I left it there because the
> > unfortunate history of the project has been the removal of comments and
> > then later rediscovery of the truth, sometimes more than once. I could
> > no longer reproduce that error; someone else may know differently.
> 
> I haven't tested this, but it appears to me that the failure would occur
> in overflow situations.  If we have too many subxacts, we'll generate
> XLOG_XACT_ASSIGNMENT, which will cause the subxids to be removed from
> KnownAssignedXids[].  Then later when the top-level xact commits or
> aborts we'll try to remove them again as a consequence of processing
> the top-level's commit/abort record.  No?

Yes, thank you for clear thinking. Anyway, looks like the comment was
right after all and the new code to throw an error is wrong in some
cases. It was useful for testing, at least. The comment was slightly
misleading, which is a good reason to rewrite it.

It seems like it might be possible to identify which xids could cause an
error and which won't. Much harder than that. We still have the possible
case where we have >64 subtransactions allocated but many of them abort
and we are left with a final commit of <64 subtransactions.

-- 
 Simon Riggs           www.2ndQuadrant.com

In response to

• Re: testing HS/SR - 1 vs 2 performance at 2010-04-27 20:18:53 from Tom Lane

Responses

• Re: testing HS/SR - 1 vs 2 performance at 2010-04-27 21:24:48 from Tom Lane

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2010-04-27 21:24:48
	Subject: Re: testing HS/SR - 1 vs 2 performance
Previous:	From: Tom Lane	Date: 2010-04-27 20:18:53
	Subject: Re: testing HS/SR - 1 vs 2 performance