On Tue, Jun 17, 2014 at 5:40 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Wed, Jun 18, 2014 at 1:40 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Mon, Jun 2, 2014 at 8:55 AM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >> I'm not sure if this is reasonably possible, but one thing that would >> make this tool a whole lot easier to use would be if you could make >> all the magic happen in a single server. For example, suppose you had >> a background process that somehow got access to the pre and post >> images for every buffer change, and the associated WAL record, and >> tried applying the WAL record to the pre-image to see whether it got >> the corresponding post-image. Then you could run 'make check' or so >> and afterwards do something like psql -c 'SELECT * FROM >> wal_replay_problems()' and hopefully get no rows back. > So your point is to have a 3rd independent server in the process that > would compare images taken from a master and its standby? Seems to > complicate the machinery.
No, I was trying to get it down form 2 servers to 1, not 2 servers up to 3. >> Don't get me wrong, having this tool at all sounds great. But I think >> to really get the full benefit out of it we need to be able to run it >> in the buildfarm, so that if people break stuff it gets noticed >> quickly. > The patch I sent has included a regression test suite making the tests > rather facilitated: that's only a matter of running actually "make > check" in the contrib repository containing the binary able to compare > buffer captures between a master and a standby. Cool! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
