Re: Online checksums verification in the backend

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Re: Online checksums verification in the backend
Date: 2019-12-09 16:21:46
Message-ID: CA+TgmoavHnO20Stahs6MPe53qBqeiaCTwsktSVd7LDW+Z9pNtw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 6, 2019 at 9:51 AM Julien Rouhaud <rjuju123(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2019-12-09 16:31:51 Re: Questions about PostgreSQL implementation details
Previous Message rajesh kumar 2019-12-09 16:21:13 Re: ERROR: uncommitted xmin 347341220 from before xid cutoff 967029200 needs to be frozen