Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant
От | Simon Riggs |
---|---|
Тема | Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant |
Дата | |
Msg-id | 1121840863.16393.6.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)
|
Список | pgsql-patches |
On Tue, 2005-07-19 at 22:24 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > Short patch enclosed to turn off writing of commit-status hint bits. > > Doesn't this entirely destroy the ability to truncate clog, and > therefore the ability to survive XID wraparound? I hope not for all our sakes, since the hint bits are not WAL logged and anything that relies upon them would be fragile. If we were going to move a table to WORM storage, then we'd have done VACUUM FREEZE first anyway, which would be required to avoid XID wraparound. This patch would then guarantee that no further system-initiated writes take place. Not AFAICS.... comments from vacuum.c included: /* * Now scan all the pages that we moved tuples onto and update tuple * status bits. This is not really necessary, but will save time for * future transactions examining these tuples. */ update_hint_bits(onerel, fraged_pages, num_fraged_pages, last_move_dest_block, num_moved); then again on the function itself... /* * update_hint_bits() -- update hint bits in destination pages * * Scan all the pages that we moved tuples onto and update tuple status bits. * This is normally not really necessary, but it will save time for future * transactions examining these tuples. * * * For the non-freeze case, one wonders whether it wouldn't be better to skip * this work entirely, and let the tuple status updates happen someplace * that's not holding an exclusive lock on the relation. */ > It probably also breaks subxact and multixact logging, but I haven't > looked closely... AFAIK this has nothing to do with that, since those locks are not persistent across a crash,,,but conceivably something in 2PC might be effected. Best Regards, Simon Riggs
В списке pgsql-patches по дате отправления: