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  (paolo romano <paolo.romano@yahoo.it>)
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:

Previous
From: Sven Geisler
Date:
Subject: Re: patch postgresql for AMD64 (Opteron)
Next
From: "Mark Woodward"
Date:
Subject: update/insert, delete/insert efficiency WRT vacuum and MVCC