Re: BUG #16285: bt_metap fails with value is out of range for type integer

Hi,

On 2020-03-09 17:16:47 -0700, Peter Geoghegan wrote:
> On Mon, Mar 9, 2020 at 3:36 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > What do you mean? Since 12 is the newest release affected, we'd
> > potentially (and with increasing likelihood due to clusters living
> > longer) have the problem till 12 is not supported anymore. What am I
> > missing?
>
> But 12 isn't the latest release affected. It just so happens that
> Victor was using 12, but oldest_xact was actually added by commit
> 857f9c36 -- that's Postgres 11.

Huh? I think we might be miscommunicating here. My point isn't about the
*earliest* release affected, it's about the *latest* version without a
fix. IOW, until when is there a supported release without a fix.

And once 12 is not supported anymore, 11 is also unsupported. So we'd
have a live bug (which would mainly hit while investigating issues)
until 12 is unsupported?

> To be very precise: I imagine that Victor was using bt_metap() in
> production on a Postgres 12 installation because he wanted to make
> sure that his installation had the new stuff (he did a talk about it
> at EU, so clearly it's of interest to him). The problem is
> nevertheless not new to Postgres 12.
>
> > I'd just do the s/%u/%d/.
>
> That's a pretty gross hack. So be it.

Yea, it is.

> > pg_class.relpages is also reported as a signed integer :(. Since
> > btm_root/fastroot use %d, it'll just have similar wrapping behaviour.
>
> I guess that means that pageinspect was correct after all!

Well, for some value of correct. I was arguing quite a while ago that we
should just make pg_class.relpages a 64bit integer, or introduce an sql
level type for block numbers.

Greetings,

Andres Freund