Re: Adding a TAP test checking data consistency on standby withminRecoveryPoint

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Adding a TAP test checking data consistency on standby withminRecoveryPoint
Дата
Msg-id 20181112040838.GA2631@paquier.xyz
обсуждение исходный текст
Ответ на Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Ответы Re: Adding a TAP test checking data consistency on standby withminRecoveryPoint  (Michael Paquier <michael@paquier.xyz>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation
Следующее
От: Amit Langote
Дата:
Сообщение: Re: BUG #15212: Default values in partition tables don't work asexpected and allow NOT NULL violation