Re: requested timeline doesn't contain minimum recovery point

From: Tom DalPozzo <t(dot)dalpozzo(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: requested timeline doesn't contain minimum recovery point
Date: 2017-01-11 10:58:17
Message-ID: CAK77FCRC074zbDQMCMA2=GE_WRzP0RyjymrfDEYPrGFbhPHaeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
>
> > I mean, could random bytes appear as a valid record (very unlikely, but
> > possible)?
>
> Yes, that could be possible if some memory or disk is broken. That's
> why, while it is important to take backups, it is more important to
> make sure that they are able to restore correctly before deploying
> them.
> --
> Michael
>
Hi,
of course against memory or disk corruption, nothing 100% safe can be done.
But, excluding these cases, can there be situations in which the WAL reader
gets confused?
I'm thinking at WAL segments recycling: when a WAL is recycled it is not
filled with anything (zeroes...) right?
If I'm right, then there are still old records in the WAL. If they're
aligned with the new offsets, I guess that the system can understand that
they're older (looking at some ID) and not valid but if not aligned, there
could be an unlucky and unlikely issue.

In other word, excluding HW problems and possible unwanted bugs, I'd like
to know if the logic underneath WAL reading at startup is 100%safe.

Regards
Pupillo

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2017-01-11 12:30:46 Re: Are new connection/security features in order, given connection pooling?
Previous Message Sairam Gaddam 2017-01-11 08:56:51 How to identify Primary key column during build stage of Custom index?