Re: Checksum errors in pg_stat_database - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Checksum errors in pg_stat_database
Date
Msg-id CABUevEzaFjtrkkRKAHCa-H9qrBz+gatGAZL7skTTM3SP4webug@mail.gmail.com
Whole thread Raw
In response to Re: Checksum errors in pg_stat_database  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Checksum errors in pg_stat_database
List pgsql-hackers
On Mon, Mar 4, 2019 at 11:31 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
On Fri, Feb 22, 2019 at 3:01 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> It tracks things that happen in the general backends. Possibly we should also consider counting the errors actually found when running base backups? OTOH, that part of the code doesn't really track things like databases (as it operates just on the raw data directory underneath), so that implementation would definitely not be as clean...

Sorry I just realized that I totally forgot this part of the thread.

While it's true that we operate on raw directory, I see that sendDir()
already setup a isDbDir var, and if this is true lastDir should
contain the oid of the underlying database.  Wouldn't it be enough to
call sendFile() using this, something like (untested):

if (!sizeonly)
- sent = sendFile(pathbuf, pathbuf + basepathlen + 1, &statbuf, true);
+ sent = sendFile(pathbuf, pathbuf + basepathlen + 1, &statbuf, true,
isDbDir ? pg_atoi(lastDir+1, 4) : InvalidOid);

and accordingly report any checksum error from sendFile()?

That seems it was easy enough. PFA an updated patch that does this, and also rebased so it doesn't conflict on oid.

(yes, while moving this from draft to publish after lunch, I realized that you put a patch togerher for about the same. So let's merge it)

--
Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Binary upgrade from <12 to 12 creates toast table forpartitioned tables
Next
From: David Rowley
Date:
Subject: Re: Should we increase the default vacuum_cost_limit?