MultiXacts & WAL
От | paolo romano |
---|---|
Тема | MultiXacts & WAL |
Дата | |
Msg-id | 20060616233546.65754.qmail@web27814.mail.ukl.yahoo.com обсуждение исходный текст |
Ответы |
Re: MultiXacts & WAL
Re: MultiXacts & WAL |
Список | 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 по дате отправления: