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
