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
signature.asc
Description: PGP signature
