Re: pg_basebackup fails on databases with high OIDs

Julien Rouhaud <rjuju123@gmail.com>

From: Julien Rouhaud <rjuju123@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Magnus Hagander <magnus@hagander.net>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-01-11T16:44:37Z
Lists: pgsql-hackers
On Sat, Jan 11, 2020 at 08:21:11AM +0100, Peter Eisentraut wrote:
> On 2020-01-06 21:00, Magnus Hagander wrote:
> > > +0.5 to avoid calling OidInputFunctionCall()
> >
> > Or just directly using atol() instead of atoi()? Well maybe not
> > directly but in a small wrapper that verifies it's not bigger than an
> > unsigned?
> >
> > Unlike in cases where we use oidin etc, we are dealing with data that
> > is "mostly trusted" here, aren't we? Meaning we could call atol() on
> > it, and throw an error if it overflows, and be done with it?
> > Subdirectories in the data directory aren't exactly "untrusted enduser
> > data"...
>
> Yeah, it looks like we are using strtoul() without additional error checking
> in similar situations, so here is a patch doing it like that.

> -								true, isDbDir ? pg_atoi(lastDir + 1, sizeof(Oid), 0) : InvalidOid);
> +								true, isDbDir ? (Oid) strtoul(lastDir + 1, NULL, 10) : InvalidOid);

Looking at some other code, I just discovered the atooid() macro that already
does the same, maybe it'd be better for consistency to use that instead?



Commits

  1. Fix base backup with database OIDs larger than INT32_MAX

  2. Track block level checksum failures in pg_stat_database