Re: [HACKERS] Custom compression methods

On Fri, Mar 19, 2021 at 4:38 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Yes, and prion's got this concerning diff:
>
> Column | Type | Collation | Nullable | Default | Storage |
> Compression | Stats target | Description
> --------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
> - f1 | integer | | | | plain |
> | |
> + f1 | integer | | | | plain | pglz
> | |
>
> Since the column is not a varlena, it shouldn't have a compression
> method configured, yet on that machine it does, possibly because that
> machine uses -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE.

I could reproduce the problem with those flags. I pushed a fix.

> Regarding your point, that does look like clutter. We don't annotate
> the dump with a storage clause unless it's non-default, so probably we
> should do the same thing here. I think I gave Dilip bad advice here...

Here's a patch for that. It's a little strange because you're going to
skip dumping the toast compression based on the default value on the
source system, but that might not be the default on the system where
the dump is being restored, so you could fail to recreate the state
you had. That is avoidable if you understand how things work, but some
people might not. I don't have a better idea, though, so let me know
what you think of this.

--
Robert Haas
EDB: http://www.enterprisedb.com