Hi,
On 2020-03-09 15:31:38 -0700, Peter Geoghegan wrote:
> On Mon, Mar 9, 2020 at 3:09 PM Andres Freund <andres@anarazel.de> wrote:
> > ISTM that we need some fix for the back-branches too. Being unable to
> > look at some indexes till 12 has aged out doesn't strike me as good.
>
> Actually, the oldest_xact field was added in Postgres 11.
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?
> > How about simply printing the wrapped value? That's far from perfect, of
> > course, but clearly better than the current situation in the back
> > branches.
>
> Would you be happy if we always raised a NOTICE that had information
> about the affected fields? I don't think that we should try to be
> clever and only do it when we know that it will fail. We should admit
> that it's broken with a HINT that gets associated with the NOTICE, in
> order to discourage relying on the number within automated tools.
I'd just do the s/%u/%d/.
> If we were to do this, it would probably only be necessary to
> backpatch to Postgres 11 and 12. Those are the only stable releases
> with the oldest_xact field. In practice, it is highly likely to be the
> thing that causes problems. We will report the root block number at a
> negative block number when it happens to exceed 2^31-1, but that
> condition is almost impossible to hit in practice, even when the index
> size is close to the system-wide limit of relation size. That's why
> nobody has complained about it in all these years.
pg_class.relpages is also reported as a signed integer :(. Since
btm_root/fastroot use %d, it'll just have similar wrapping behaviour.
Greetings,
Andres Freund