On Fri, Jun 13, 2014 at 4:50 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Jun 13, 2014 at 4:48 PM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: >> On 06/13/2014 10:14 AM, Michael Paquier wrote: >>> >>> On Mon, Jun 2, 2014 at 9:55 PM, Michael Paquier >>> <michael.paqu...@gmail.com> wrote: >>>> >>>> On Wed, Apr 23, 2014 at 9:43 PM, Heikki Linnakangas >>>> <hlinnakan...@vmware.com> wrote: >>>> Perhaps there are parts of what is proposed here that could be made >>>> more generalized, like the masking functions. So do not hesitate if >>>> you have any opinion on the matter. >>> >>> OK, attached is the result of this hacking: >>> >>> Buffer capture facility: check WAL replay consistency >>> >>> It is a tool aimed to be used by developers and buildfarm machines >>> that can be used to check for consistency at page level when replaying >>> WAL files among several nodes of a cluster (generally master and >>> standby node). >>> >>> This facility is made of two parts: >>> - A server part, where all the changes happening at page level are >>> captured and inserted in a file called buffer_captures located at the >>> root of PGDATA. Each buffer entry is masked to make the comparison >>> across node consistent (flags like hint bits for example) and then >>> each buffer is captured is with the following format as a single line >>> of the output file: >>> LSN: %08X/%08X page: PAGE_IN_HEXA >>> Hexadecimal format makes it easier to detect differences between >>> pages, and format is chosen to facilitate comparison between buffer >>> entries. >>> - A client part, located in contrib/buffer_capture_cmp, that can be >>> used to compare buffer captures between nodes. >> >> >> Oh, you moved the masking code from the client tool to the backend. Why? >> When debugging, it's useful to have the genuine, non-masked page image >> available. > My thought is to share the CPU effort of masking between backends... And that having a set of API to do page masking on the server side would be useful for extensions as well. Now that I recall this was one of the first things that came to my mind when looking at this facility, thinking that it would be useful to have them in a separate file, with a dedicated header. -- Michael
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers