Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Jason Harvey <jason(at)reddit(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, "Tharakan, Robins" <tharar(at)amazon(dot)com>
Subject: Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
Date: 2024-05-16 06:11:37
Message-ID: ECFFD994-D2A9-4E74-A607-01AF4C252340@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> On 5 Jul 2022, at 18:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Given the lack of field complaints, it's probably not worth trying
> to do anything to restore that capability. But we really ought to
> update pg_upgrade's code and docs in pre-v15 branches to say that
> the minimum supported source version is 9.0.

(reviving an old thread from the TODO)

Since we never got around to doing this we still refer to 8.4 as a possible
upgrade path in v14 and older.

There seems to be two alternatives here, either we bump the minimum version in
v14-v12 to 9.0 which is the technical limitation brought by 695b4a113ab, or we
follow the direction taken by e469f0aaf3c and set 9.2. e469f0aaf3c raised the
minimum supported version to 9.2 based on the complexity of compiling anything
older using a modern toolchain.

It can be argued that making a change we don't cover with testing is unwise,
but we clearly don't test the current code either since it's broken.

The attached takes the conservative approach of raising the minimum supported
version to 9.0 while leaving the code to handle 8.4 in place. While it can be
removed, the risk/reward tradeoff of gutting code in backbranches doesn't seem
appealing since the code will be unreachable with this check anyways.

Thoughts?

--
Daniel Gustafsson

Attachment Content-Type Size
0001-Refuse-upgrades-from-pre-9.0-clusters.patch application/octet-stream 2.2 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message HORDER Philip 2024-05-16 10:08:12 Re: Restore of a reference database kills the auto analyze processing.
Previous Message milist ujang 2024-05-16 04:01:27 db was corrupted, ERROR: cannot freeze committed xmax; fix by deleting rows in catalog tables

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-05-16 06:19:42 Re: PostgreSQL 17 Beta 1 release announcement draft
Previous Message Peter Smith 2024-05-16 06:04:56 Re: Pgoutput not capturing the generated columns