Re: WAL replay bugs - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: WAL replay bugs
Date
Msg-id CAB7nPqSbgjOYf_kQWXhY4jUS42WQV3LZRcppzR2R+v3XTUvkGg@mail.gmail.com
Whole thread Raw
In response to WAL replay bugs  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: WAL replay bugs  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Tue, Apr 8, 2014 at 3:16 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
>
> I've been playing with a little hack that records a before and after image
> of every page modification that is WAL-logged, and writes the images to a
> file along with the LSN of the corresponding WAL record. I set up a
> master-standby replication with that hack in place in both servers, and ran
> the regression suite. Then I compared the after images after every WAL
> record, as written on master, and as replayed by the standby.
Assuming that adding some dedicated hooks in the core able to do
actions before and after a page modification occur is not *that*
costly (well I imagine that it is not acceptable in terms of
performance), could it be possible to get that in the shape of a
extension that could be used to test WAL record consistency? This may
be an idea to think about...
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Default gin operator class of jsonb failing with index row size maximum reached
Next
From: Robert Haas
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement