On Mon, Dec 28, 2015 at 8:50 PM, <Marek.Petr@tieto.com> wrote:
> Tried to use pageinspect module for affected pages from last two occurences:
>
> 2015-12-15 13:05:39 CET @ WARNING: page 4333275 of relation base/16422/17230 is uninitialized
> 2015-12-22 00:25:11 CET @ WARNING: page 71566 of relation base/16422/23253 is uninitialized
>
> Following outputs are the same for master and slave:
>
> [results]
Hm, OK.
> Non-default pars:
>
> [params]
There is nothing fishy here.
> Slave rebuilded and it's running almost a week for now.
Hm. Has this slave replayed the same WAL records as the slave that has
failed previously? Or did it use a fresher base backup? If that's the
latter the problem would have been fixed by itself for those two
relation pages as they would have been correctly created by the base
backup and not the WAL replay. Perhaps that's too late, but could it
be possible to scan the WAL segments you have and see if there is
record referring to those pages being initialized or not? You would
need to find a record like that:
[insert|update|multi-insert|hot_update](init) rel %u/%u/%u; tid %u/%u
tid is t_ctid referred in those upper results you just sent. And this
record should normally be present before the ones that caused the
PANIC setting the visibility map bit. If that's not the case, it may
be possible that there is actually a bug if the page is not found as
being initialized properly first. At least we are sure that the
corruption is not coming from the master.
--
Michael