Horton

Re: [HACKERS] Custom compression methods

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, 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
Date: 2021-03-07T07:17:03Z
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

Commits

  1. docs: Update TOAST storage docs for configurable compression.

  2. Further tweaking of pg_dump's handling of default_toast_compression.

  3. Fix interaction of TOAST compression with expression indexes.

  4. Tidy up more loose ends related to configurable TOAST compression.

  5. Short-circuit slice requests that are for more than the object's size.

  6. Mostly-cosmetic adjustments of TOAST-related macros.

  7. Remove useless configure probe for <lz4/lz4.h>.

  8. Error on invalid TOAST compression in CREATE or ALTER TABLE.

  9. docs: Fix omissions related to configurable TOAST compression.

  10. More code cleanup for configurable TOAST compression.

  11. Bring configure support for LZ4 up to snuff.

  12. Make compression.sql regression test independent of default.

  13. Use valid compression method in brin_form_tuple

  14. Fix up pg_dump's handling of per-attribute compression options.

  15. Allow configurable LZ4 TOAST compression.

  16. Fix inconsistencies in the code

  17. Mostly-cosmetic improvements in memory chunk header alignment coding.

  18. Allow numeric to use a more compact, 2-byte header in many cases.