pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
Date: Tue, 7 Dec 2021 10:26:13 -0800
Message-ID: <75CEAC23-E6A1-4976-8CFF-AD7B24647A7C@enterprisedb.com> (raw )
In-Reply-To: <CA+TgmoYeJt5FU5eHQ4FNxJEuDO2NJjz81quU2fSt=zQhwFU8vw@mail.gmail.com >
References: <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com >
<202110222351.3f42l5fgo3lw@alvherre.pgsql >
<CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com >
<3783090.1635111977@sss.pgh.pa.us >
<CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com >
<3883429.1635171820@sss.pgh.pa.us >
<20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de >
<c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net >
<22018.1635202338@sss.pgh.pa.us >
<d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com >
<20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de >
<196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com >
<2316211.1638556231@sss.pgh.pa.us >
<CA+Tgmob0V3dJ57vKL1iouk1oLMFn-60eAUQ+ab6=1BDG7ZC8iw@mail.gmail.com >
<2978297.1638751274@sss.pgh.pa.us >
<CA+TgmobDY0ShV2Nso4x3mgLSA1dPvfi3KB9CK=Jo-USjWLskGA@mail.gmail.com >
<3361296.1638825548@sss.pgh.pa.us >
<CA+TgmoYeJt5FU5eHQ4FNxJEuDO2NJjz81quU2fSt=zQhwFU8vw@mail.gmail.com >
> On Dec 7, 2021, at 8:33 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> However, it wouldn't be a great idea to back-patch a
> completely arbitrary subset of our fixes into those branches, because
> then it sort of gets confusing to understand what the status of that
> branch is. I don't know that I'm terribly bothered by the idea that
> the behavior of the branch might deviate from the last official
> release, because most bug fixes are pretty minor and wouldn't really
> affect testing much, but it would be a little annoying to explain to
> users that those branches contain an arbitrary subset of newer fixes,
> and a little hard for us to understand what is and is not there.
Wouldn't you be able to see what changed by comparing the last released tag for version X.Y against the RELX_Y_STABLE branch? Something like `git diff REL8_4_22 origin/REL8_4_STABLE > buildability.patch`?
Having such a patch should make reproducing old corruption bugs easier, as you could apply the buildability.patch to the last branch that contained the bug. If anybody did that work, would we want it committed somewhere? REL8_4_19_BUILDABLE or such? For patches that apply trivially, that might not be worth keeping, but if the merge is difficult, maybe sharing with the community would make sense.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
view thread (70+ messages) latest in thread
Message-ID: <75CEAC23-E6A1-4976-8CFF-AD7B24647A7C@enterprisedb.com>
Permalink: ../75CEAC23-E6A1-4976-8CFF-AD7B24647A7C@enterprisedb.com/
Also on: postgresql.org/message-id/75CEAC23-E6A1-4976-8CFF-AD7B24647A7C@enterprisedb.com
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: mark.dilger@enterprisedb.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, andrew@dunslane.net, peter.eisentraut@enterprisedb.com, andres@anarazel.de, bruce@momjian.us, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_dump versus ancient server versions
In-Reply-To: <75CEAC23-E6A1-4976-8CFF-AD7B24647A7C@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox