MultiXacts & WAL - Mailing list pgsql-hackers

From paolo romano
Subject MultiXacts & WAL
Date
Msg-id 20060616233546.65754.qmail@web27814.mail.ukl.yahoo.com
Whole thread Raw
Responses Re: MultiXacts & WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: MultiXacts & WAL  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
I am  working on a possible extension of postgresql mvcc to support very timely failure masking in the context of
three-tierapplications so i am currently studying Postgresql internals...<br /><br />I am wondering what are the
reasonswhy both the MultiXactIds and the corresponding OFFSETs and MEMBERs are currently persisted.<br />In multixact.c
'sdocumentation on the top of the file you can find the following statement:<br />"...This allows us to completely
rebuildthe data entered since the last checkpoint during XLOG replay..."<br /><br />I can see the need to persist (not
eagerly)multixactids to avoid wraparounds. Essentially, mass storage is used to extend the limited capabity of slrus
datastructures in shared memory.<br /><br />The point i am missing is the need to be able to completely recover
multixactsoffsets and members data. These carry information about current transactions holding shared locks on db
tuples,which should not be essential for recovery purposes. After a crash you want to recover the content of your data,
notthe presence of shared locks on any tuple. AFAICS, this seems true for both committed/aborted transactions (which
beingconcluded do not care any more about the fact that they could have held any shared lock), as well as prepared
transactions(which only need to recover their exclusive locks).<br /><br />I have tried to dig around the comments
withinthe main multixact.c functions and i have walked through this comment (CreateMultiXactId())):<br /><br />"...The
onlyway for the MXID to be referenced from any data page is for heap_lock_tuple() to have put it there, and
heap_lock_tuple()generates  an XLOG record that must follow ours... "<br /><br />But still I cannot see the need to
recovercomplete shared locks info (i.e. not only multixactids but also the corresponding registered transactionids that
wereholding the lock)...<br /><br />May be this is needed to support savepoints/subtransactions? Or is it something
elsethat i am missing?<br /><br />Thanks for your precious help!<br /><br />    Paolo<span class="comment"><br
/></span><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: Josh Berkus
Date:
Subject: Register for an SPI Contributing Membership
Next
From: Tom Lane
Date:
Subject: Re: MultiXacts & WAL