Re: [HACKERS] Custom compression methods

On Sun, Mar 07, 2021 at 12:16:41PM +0530, Dilip Kumar wrote:
> > If I pg_upgrade from an binary with-lz4 to one without-lz4, it fails
> > while restoring the schema, after running check, which is bad:
> > | pg_restore: error: could not execute query: ERROR: not built with lz4 support
> > |CREATE TABLE "public"."a" (
> > | "t" "text" COMPRESSION lz4,

Actually, it looks like pg_upgrading an xml column works, but calling xml
functions fails.

I think that's a deficiency in pg_upgrade - it should be caught early during
the --check phase and not after dumping and in the middle of restoring the
schema (which can sometimes take significant time).

> > For comparison, upgrading from binaries with-libxml to binaries without-libxml
> > actualy passes pg_upgrade.
> >
> > It's arguable which behavior is desirable:
> > - allow CREATE TABLE(..COMPRESSION lz4) during pg_upgrade;
> > - allow CREATE TABLE(..COMPRESSION lz4) always. This has the advantage that
> > GetAttributeCompression() doesn't have conditional compilation. This seems
> > to be parallel to the libxml case - apparently, it's possible to create an
> > XML column, but not insert into it.
>
> IMHO we can always allow creating the table with lz4 and only error
> out when we really need to compress/decompress the data. I like this
> behavior because it is the same as libxml. But I am fine with
> allowing it only in binary upgrade also. Another option could be to
> fall back to default "pglz" in binary upgrade mode if it is built
> without-lz4 but the problem is this will change the table
> specification after the upgrade.

No, you certainly can't do that.
You'd have a table defined as pglz but with lz4 in the data files.
In the best case, it would give errors about corrupt lz4 data.

--
Justin