From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint |
Date: | 2018-11-12 04:08:38 |
Message-ID: | 20181112040838.GA2631@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 09, 2018 at 12:42:27PM +0000, Andrew Gierth wrote:
> Seems simple enough - the LSN on the page is actually two 4-byte values
> with the most significant one first, regardless of platform byte order
> (though each individual word is in native order), so
>
> my ($hi,$lo) = unpack("LL", $buf);
>
> should suffice. ("L" is always 32 bits regardless of platform, and it
> has the platform's endianness.)
Thanks for the review, Andrew. And I completely forgot that this is at
the beginning of the page.
> Looking only at the last page seems questionable.
I have switched also the online check so as it also looks at the full
range of blocks instead of only the last one.
> Something like this should work to return the largest LSN of any page
> in the specified list of files:
>
> # find_largest_lsn(blocksize,filenames...)
> sub find_largest_lsn
Thanks! I am stealing that stuff, and I have added an offline check by
comparing the value of minRecoveryPoint in pg_controldata. Again, if
you revert c186ba13 and run the tests, both online and offline failures
are showing up.
What do you think?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
recovery-min-lsn-tap-v2.patch | text/x-diff | 7.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-11-12 04:17:35 | Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation |
Previous Message | Tom Lane | 2018-11-12 03:59:59 | Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation |