On Mon, Mar 08, 2021 at 03:26:04PM -0500, Robert Haas wrote: > On Mon, Mar 8, 2021 at 5:02 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > So now only pending point is, how do we handle the upgrade when you > > are upgrading from --with-lz4 to --without-lz4 binary and a couple of > > options discussed here are > > a) Should we allow table creation with lz4 even if it is compiled > > --without-lz4? In case of xml we always allow table creation even if > > it is compiled --wthout-libxml > > b) Instead of allowing this always, only allow during binary upgrade.
> It would be nice to have a way to force > anything compressed with the old method to be re-compressed with the > new method, but not having that doesn't preclude allowing the > parameter to be changed. Doesn't vacuum full/cluster/dump+restore do that ? > I think the pg_dump argument should be --no-toast-compression, not > --no-toast-compressions. I agree with Justin that pg_restore should > have the option also. I mentioned that this is hard to do, since the compression is stored inside the text blob that creates the whole table...Unless toast compression is a per-relation property rather than per-attribute. I don't think pg_restore should try to reverse-engineer the text output by pg_dump to elide the "COMPRESSION lz4". I think maybe CREATE shouldn't support COMPRESSION at all, and pg_dump/restore would use ALTER. That makes this very slightly less of an issue, as one can use pg_restore -f- |grep -v '^ALTER TABLE .* SET COMPRESSION' |psql -d, rather than sed 's/COMPRESSION lz4//' > Man, it would be really nice to be able to set the default for new > tables, rather than having all these places hard-coded to use > DefaultCompressionMethod. Surely lotsa people are going to want to set > toast_compression = lz4 in postgresql.conf and forget about it. I don't understand - isn't that what 0002 does ? Subject: [PATCH v32 2/4] Add default_toast_compression GUC -- Justin