Re: pg_upgrade test for binary compatibility of core data types

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us, peter(dot)eisentraut(at)enterprisedb(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, buschmann(at)nidsa(dot)net, andrew(at)dunslane(dot)net, noah(at)leadboat(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us, andres(at)anarazel(dot)de
Subject: Re: pg_upgrade test for binary compatibility of core data types
Date: 2021-12-01 07:19:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

On Thu, Nov 18, 2021 at 03:58:18PM +0900, Michael Paquier wrote:
> + ver >= 905 AND ver <= 1300 AS oldpgversion_95_13,
> + ver >= 906 AND ver <= 1300 AS oldpgversion_96_13,
> + ver >= 906 AND ver <= 1000 AS oldpgversion_96_10,
> So here, we have the choice between conditions that play with version
> ranges or we could make those checks simpler but compensate with a set
> of IF EXISTS queries. I think that your choice is right. The
> buildfarm mixes both styles to compensate with the cases where the
> objects are created after a drop.

So, I have come back to this part of the patch set, that moves the SQL
queries doing the pre-upgrade cleanups in the old version we upgrade
from, and decided to go with what looks like the simplest approach,
relying on some IFEs depending on the object types if they don't
exist for some cases.

While checking the whole thing, I have noticed that some of the
operations were not really necessary. The result is rather clean now,
with a linear organization of the version logic, so as it is a
no-brainer to get that done in back-branches per the
backward-compatibility argument.

I'll get that done down to 10 to maximize its influence, then I'll
move on with the buildfarm code and send a patch to plug this and
reduce the dependencies between core and the buildfarm code.

Attachment Content-Type Size
0001-Move-SQLs-for-cleanups-before-cross-version-upgrades.patch text/x-diff 6.2 KB

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-12-01 13:59:30 BUG #17305: to_timestamp accept dates rejected by timestamptz cast
Previous Message PG Bug reporting form 2021-11-30 14:09:15 BUG #17304: Test failure with -fsanitize=undefined

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-12-01 07:30:30 Re: fix a typo in slotfuncs.c
Previous Message SATYANARAYANA NARLAPURAM 2021-12-01 07:08:21 Re: pg_replslotdata - a tool for displaying replication slot information