On Tue, Jun 15, 2021 at 08:08:54AM +0300, Heikki Linnakangas wrote:
> On 15/06/2021 06:42, Justin Pryzby wrote:
>> Why ? This is WAL, not table data. WAL depends on the major version, so
>> I think wal_compression could provide a different set of compression methods at
>> every major release?
That may finish by being annoying to the user, but perhaps that you
are right that we could have more flexibility here. That does not
change the fact that we'd better choose something wisely, able to
stick around for a couple of years at least, rather than revisiting
this choice every year.
>> Actually, I was just thinking that default yes/no/on/off stuff maybe should be
>> defined to mean "lz4" rather than meaning pglz for "backwards compatibility".
>
> +1
I am not sure that we have any reasons to be that aggressive about
this one either, and this would mean that wal_compression=on implies a
different method depending on the build options. I would just stick
with the past, careful practice that we have to use a default
backward-compatible value as default, while being able to use a new
option.
--
Michael