Re: Online checksums verification in the backend - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Online checksums verification in the backend
Date
Msg-id CA+TgmoavHnO20Stahs6MPe53qBqeiaCTwsktSVd7LDW+Z9pNtw@mail.gmail.com
Whole thread Raw
In response to Online checksums verification in the backend  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Online checksums verification in the backend  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Fri, Dec 6, 2019 at 9:51 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> This topic was discussed several times, with the most recent
> discussions found at [1] and [2].  Based on those discussions, my
> understanding is that the current approach in BASE_BACKUP has too many
> drawbacks and we should instead do this check in the backend.

Good idea.

> This brings the second consideration: how to report the list corrupted
> blocks to end users.  As I said this is for now returned via the SRF,
> but this is clearly not ideal and should rather be made available more
> globally.

Some people might prefer notices, because you can get those while the
thing is still running, rather than a result set, which you will only
see when the query finishes. Other people might prefer an SRF, because
they want to have the data in structured form so that they can
postprocess it. Not sure what you mean by "more globally." I guess one
idea would be to provide a way to kick this off in the background via
a background worker or similar and then have it put the results in a
table. But that might fail if there are checksum errors in the
catalogs themselves.

I don't really know what's best.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: rajesh kumar
Date:
Subject: Re: ERROR: uncommitted xmin 347341220 from before xid cutoff967029200 needs to be frozen
Next
From: Mark Dilger
Date:
Subject: Re: Questions about PostgreSQL implementation details