From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, David Steele <david(at)pgmasters(dot)net>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [HACKERS] Custom compression methods |
Date: | 2021-03-07 07:17:03 |
Message-ID: | 20210307071703.GY29832@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2021-03-07 07:28:10 | Re: pg_stat_statements oddity with track = all |
Previous Message | Dilip Kumar | 2021-03-07 06:46:41 | Re: [HACKERS] Custom compression methods |