Re: testing HS/SR - 1 vs 2 performance
От | Simon Riggs |
---|---|
Тема | Re: testing HS/SR - 1 vs 2 performance |
Дата | |
Msg-id | 1272401072.4161.8226.camel@ebony обсуждение исходный текст |
Ответ на | Re: testing HS/SR - 1 vs 2 performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: testing HS/SR - 1 vs 2 performance
|
Список | pgsql-hackers |
On Tue, 2010-04-27 at 16:18 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndQuadrant.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
В списке pgsql-hackers по дате отправления: