| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, David Steele <david(at)pgmasters(dot)net> |
| Subject: | Re: basebackup checksum verification |
| Date: | 2019-03-27 01:07:20 |
| Message-ID: | 20190327010720.GI6197@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greetings,
* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2019-03-26 21:01:27 -0400, Stephen Frost wrote:
> > I'm also not convinced that these changes to pg_basebackup will be free
> > of issues that may impact users in a negative way, making me concerned
> > that we're going to end up doing more harm than good with such a change
> > being back-patched. Simply comparing the skipped LSNs to the
> > end-of-backup LSN seems much less invasive when it comes to this core
> > code, and certainly increases the chances quite a bit that we'll detect
> > an issue with corruption in the LSN.
>
> Yea, in the other thread we'd discussed that that might be the correct
> course for backpatch, at least initially. But I think the insert/replay
> LSN would be the correct LSN to compare to in the basebackup.c case?
Yes, it seems like that could be done in the basebackup case and would
avoid the need to track the skipped LSNs, since you could just look up
the insert/replay LSN at the time and do the comparison right away.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2019-03-27 01:16:54 | Re: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
| Previous Message | Andres Freund | 2019-03-27 01:04:58 | Re: basebackup checksum verification |