Re: [COMMITTERS] pgsql: Do a pass of code review for the ALTER TABLE - Mailing list pgsql-hackers
From | paolo romano |
---|---|
Subject | Re: [COMMITTERS] pgsql: Do a pass of code review for the ALTER TABLE |
Date | |
Msg-id | 20060703125950.27703.qmail@web27805.mail.ukl.yahoo.com Whole thread Raw |
In response to | Re: [COMMITTERS] pgsql: Do a pass of code review for the ALTER TABLE (Alvaro Herrera <alvherre@commandprompt.com>) |
Responses |
MultiXactID Wrap-Around
|
List | pgsql-hackers |
<span style="font-family: times new roman;">I'm keeping on studying multixact.c and log management, and I hope you can helpme, as usual, in clearing my doubts.</span><br style="font-family: times new roman;" /><br style="font-family: timesnew roman;" /><span style="font-family: times new roman;">My doubts now concern MultixactID wrap-around management.</span><br style="font-family: times new roman;" /><span style="font-family: times new roman;">Afaics, it is possibleto spawn multixactids so quickly to have a wrap-around and to start overwriting the data stored in the offset slru(but analogous considerations apply to the member slru as well). This would cause corruption, if the overwritten infowas still needed, e.g., by a (very) long-running transaction. This is of course very unlikely in practice, but yet stillpossible in theory.</span><br style="font-family: times new roman;" /><br style="font-family: times new roman;" /><spanstyle="font-family: times new roman;">In GetNewMultiXactId () wrap-around of MultiXactId seems to be simply handledthis way:</span><br style="font-family: times new roman;" /><pre class="fragment" style="font-family: times new roman;">00780 <span class="comment">_/* Handle wraparound of the nextMXact counter */</span><br />00781 <span class="keywordflow">if</span>(<a class="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/multixact_8c.html#a16"target="_blank">MultiXactState</a>-><a class="code"href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/structMultiXactStateData.html#o0" target="_blank">nextMXact</a>< <a class="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/multixact_8h.html#a1"target="_blank">FirstMultiXactId</a>)<br />00782 <a class="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/multixact_8c.html#a16" target="_blank">MultiXactState</a>-><aclass="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/structMultiXactStateData.html#o0"target="_blank">nextMXact</a> =<a class="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/multixact_8h.html#a1" target="_blank">FirstMultiXactId</a>;</pre><brstyle="font-family: times new roman;" /><span style="font-family: times newroman;">I cannot see how this may avoid possible overwriting of still needed <span style="text-decoration: underline;">data.</span>To address such an issue shouldn't one need to check against </span><a class="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/multixact_8c.html#a17"style="font-family: times new roman;" target="_blank">OldestMemberMXactId</a><spanstyle="font-family: times new roman;">, </span><a class="code" href="http://www.mcknight.de/pgsql-doxygen/cvshead/html/multixact_8c.html#a18"style="font-family: times new roman;" target="_blank">OldestVisibleMXactId?</a>Or, alternatively, rely on an approach similar to the one taken to handle standardXID generation (xidWarnLimit, see GetNewTransactionId)?<span style="font-family: monospace;"><span style="text-decoration:underline;"><br /><br /></span></span>Is it me who's missing something or is it just that such a casehas been considered so unlikely not to motivate additional overheads/checks?<br /><br />Thanks in advance!<br /><br /> Paolo<p> Chiacchiera con i tuoi amici in tempo reale! <br /> http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
pgsql-hackers by date: