On Fri, Mar 19, 2021 at 4:38 PM Robert Haas <robertmh...@gmail.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
non-default-toast-compression-only-v1.patch
Description: Binary data
