From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
        Dilip Kumar <dilipbalaut@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Andres Freund <andres@anarazel.de>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Alexander Korotkov <a.korotkov@postgrespro.ru>,
        David Steele <david@pgmasters.net>,
        Ildus Kurbangaliev <i.kurbangaliev@gmail.com>,
        Dmitry Dolgov <9erthalion6@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] Custom compression methods
In-reply-to: <20210324175815.GE15100@telsasoft.com>
References: <20210320074420.GR11765@telsasoft.com>
 <CAFiTN-uX=hLscjL=0raA6dYcoiZB=9YqL3DmX15CMvZiu+WB+w@mail.gmail.com>
 <20210320153933.GT11765@telsasoft.com> <229250.1616261775@sss.pgh.pa.us>
 <261449.1616267030@sss.pgh.pa.us>
 <fe462d41-7063-72a1-2e70-0300c53ee2c4@dunslane.net>
 <1099280.1616600518@sss.pgh.pa.us>
 <CA+TgmoZh+1LrD3SnvNrpx-poxoMOA6C0QVAN_++ZAUxsrkDM4Q@mail.gmail.com>
 <20210324172450.GD15100@telsasoft.com>
 <CA+TgmoYJMfADAaCTUHCOuZyXE=hA1JRnLtyt4X6R-Cd0FFaZcw@mail.gmail.com>
 <20210324175815.GE15100@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Wed, 24 Mar 2021 12:58:15 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1112851.1616609702.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Mar 2021 14:15:02 -0400
Message-ID: <1112852.1616609702@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1112852.1616609702%40sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Wed, Mar 24, 2021 at 01:30:26PM -0400, Robert Haas wrote:
>> ... So --no-toast-compression is just fine for people who are
>> dumping and restoring, but it's no help at all if you want to switch
>> TOAST compression methods while doing a pg_upgrade. However, what does
>> help with that is sticking with what Tom committed before rather than
>> changing to what he's proposing now.

> I don't know what/any other cases support using pg_upgrade to change stu=
ff like
> the example (changing to lz4).  The way to do it is to make the changes =
either
> before or after.  It seems weird to think that pg_upgrade would handle t=
hat.

Yeah; I think the charter of pg_upgrade is to reproduce the old database
state.  If you try to twiddle the process to incorporate some changes
in that state, maybe it will work, but if it breaks you get to keep both
pieces.  I surely don't wish to consider such shenanigans as supported.

But let's ignore the case of pg_upgrade and just consider a dump/restore.
I'd still say that unless you give --no-toast-compression then I would
expect the dump/restore to preserve the tables' old compression behavior.
Robert's argument that the pre-v14 database had no particular compression
behavior seems nonsensical to me.  We know exactly which compression
behavior it has.

			regards, tom lane