Re: pg_basebackup fails on databases with high OIDs - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: pg_basebackup fails on databases with high OIDs
Date
Msg-id CAOBaU_bNB5_-6XHdebsPrrX29v-=WqMMaiPnNsjQmpjvw+QH3g@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup fails on databases with high OIDs  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_basebackup fails on databases with high OIDs  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Mon, Jan 6, 2020 at 9:21 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Jan 06, 2020 at 09:07:26AM +0100, Peter Eisentraut wrote:
> > This is a new bug in PG12.  When you have a database with an OID above
> > INT32_MAX (signed), then pg_basebackup fails thus:
>
> Yep.  Introduced by 6b9e875.

Indeed.

> > pg_basebackup: error: could not get write-ahead log end position from
> > server: ERROR:  value "3000000000" is out of range for type integer
> >
> > The cause appears to be commit 6b9e875f7286d8535bff7955e5aa3602e188e436.
> >
> > A possible fix is attached.  An alternative to using OidInputFunctionCall()
> > would be exporting something like oidin_subr().
>
> I think that you would save yourself from a lot of trouble if you do
> the latter with a subroutine.  Not quite like that based on the
> process context where the call is done, but remember 21f428eb..

+0.5 to avoid calling OidInputFunctionCall()



pgsql-hackers by date:

Previous
From: Surafel Temesgen
Date:
Subject: Re: A rather hackish POC for alternative implementation of WITH TIES
Next
From: Dilip Kumar
Date:
Subject: Re: adding partitioned tables to publications