Re: visibilitymap_clear()s in vacuumlazy.c aren't WAL logged

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: visibilitymap_clear()s in vacuumlazy.c aren't WAL logged
Date: 2016-07-16 11:41:34
Message-ID: CAB7nPqQLCu60LCmF9_+jofa3oVOqLFnKfckJD0HZzjNz86Y97w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 16, 2016 at 10:23 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> The $subject says it all. Am I missing something, or is that not ok?

Indeed, it would be a good thing to get those sanity checks logged so
as standbys get the call, or at least perform the sanity check as well
on the block that the system is warning about. It seems to me that
logging the VM bit would be an interesting option as well, bringing to
the fact that there should be dedicated WAL records.

(By the way, adding a check for the case where a page contains
non-frozen tuples but the VM has the all-frozen bit set would be good
as well)

> Now, these branches should never be hit, but it surely isn't good that
> the corruption will persist on a primary, after it's explicitly been
> fixed on the standby.

"primary" and "standby" are reversed here?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-07-16 11:59:30 Re: Regression tests vs existing users in an installation
Previous Message Amit Kapila 2016-07-16 11:10:52 Re: Reviewing freeze map code