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
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 |