Re: collateral benefits of a crash-safe visibility map - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: collateral benefits of a crash-safe visibility map
Date
Msg-id BANLkTi=ccHhH_zu=1v3mVOjK=+1L-WD8+A@mail.gmail.com
Whole thread Raw
In response to Re: collateral benefits of a crash-safe visibility map  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, May 10, 2011 at 6:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, May 10, 2011 at 12:57 PM, Simon Riggs <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Formatting Curmudgeons WAS: MMAP Buffers
Next
From: Peter Geoghegan
Date:
Subject: Re: Process wakeups when idle and power consumption