Re: collateral benefits of a crash-safe visibility map

On Tue, May 10, 2011 at 6:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, May 10, 2011 at 12:57 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> 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