Re: collateral benefits of a crash-safe visibility map
От
Simon Riggs
Тема
Re: collateral benefits of a crash-safe visibility map
Дата
Msg-id
BANLkTi=ccHhH_zu=1v3mVOjK=+1L-WD8+A@mail.gmail.com
Ответ на
Список
Дерево обсуждения
collateral benefits of a crash-safe visibility map Robert Haas <robertmhaas@gmail.com>
Re: collateral benefits of a crash-safe visibility map Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: collateral benefits of a crash-safe visibility map Merlin Moncure <mmoncure@gmail.com>
Re: collateral benefits of a crash-safe visibility map Simon Riggs <simon@2ndQuadrant.com>
Re: collateral benefits of a crash-safe visibility map Robert Haas <robertmhaas@gmail.com>
Re: collateral benefits of a crash-safe visibility map Tom Lane <tgl@sss.pgh.pa.us>
Re: collateral benefits of a crash-safe visibility map Simon Riggs <simon@2ndQuadrant.com>
Re: collateral benefits of a crash-safe visibility map Simon Riggs <simon@2ndQuadrant.com>
Re: collateral benefits of a crash-safe visibility map Robert Haas <robertmhaas@gmail.com>
On Tue, May 10, 2011 at 6:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, May 10, 2011 at 12:57 PM, Simon Riggs wrote: >>> Hmmm, do we really need to WAL log freezing? > >> That might solve the relfrozenxid problem - set the bits in the heap, >> sync the heap, then update relfrozenxid once the heap is guaranteed >> safely on disk - but it again seems problematic for Hot Standby. > > ... or even warm standby. You basically *have to* WAL-log freezing > before you can truncate pg_clog. The only freedom you have here is > freedom to mess with the policy about how soon you try to truncate > pg_clog. > > (Doing an unlogged freeze operation first is right out, too, if it > causes the system to fail to perform/log the operation later.) Trying to think outside of the box from all these things we can't do. Can we keep track of the relfrozenxid and then note when we fsync the relevant file, then issue a single WAL record to indicate that? Still WAL logging, but 1 record per table, not 1 record per tuple. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления