Re: [HACKERS] Custom compression methods

On Sun, Mar 07, 2021 at 01:36:50PM +0530, Dilip Kumar wrote:
> On Sun, Mar 7, 2021 at 12:47 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> > > 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.
>
> Yeah, we can not do that. Just missed that part :)

But I believe what you're thinking is that it ought to be possible to restore a
backup, even if the binaries in the target cluster don't support the
compression used by the source tables.

Earlier in this thread, I suggested to implement an option to pg_restore to
avoid outputting compression, in order to allow restoring with a different
compression (by using the default_toast_compression GUC). Now, it seems like
that's even more important, to allow restoring into binaries --without-lz4.
(the pg_dump isn't in LZ4 format, it just needs to not say "COMPRESSION LZ4").

I think you're planning to allow the CREATE TABLE to succeed in any case, but
it's not helpful if the DBA has to restore the schema, and then alter all the
text columns to set PGLZ, and then restore the data and post-data.

Also, I suggest to rename the pg_dump option:
| --no-compression-methods do not dump compression methods

I have a patch to pg_dump to support alternate compression in the dump itself
(in addition to zlib), so the name will be confusing. I suggest
--no-toast-compression, like the GUC. And the same for pg_restore.

--
Justin