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

From Julien Rouhaud
Subject Re: Checksum errors in pg_stat_database
Date
Msg-id CAOBaU_Yabyk5x11=YdDuqYYmJjJKZMcosR_55MHanZVG-9anfw@mail.gmail.com
Whole thread Raw
In response to Re: Checksum errors in pg_stat_database  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Mon, Mar 4, 2019 at 8:31 PM 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
foundwhen running base backups? OTOH, that part of the code doesn't really track things like databases (as it operates
juston 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()?

So this seem to work just fine without adding much code.  PFA v3 of
Magnus' patch including error reporting for BASE_BACKUP.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Oddity with parallel safety test for scan/join target in grouping_planner
Next
From: Julien Rouhaud
Date:
Subject: Re: Ordered Partitioned Table Scans