On Wed, Dec 3, 2014 at 12:35 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Dec 2, 2014 at 7:16 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> In the latest versions of the patch, control of compression is done
>> within full_page_writes by assigning a new value 'compress'. Something
>> that I am scared of is that if we enforce compression when
>> full_page_writes is off for forcibly-written pages and if a bug shows
>> up in the compression/decompression algorithm at some point (that's
>> unlikely to happen as this has been used for years with toast but
>> let's say "if"), we may corrupt a lot of backups. Hence why not simply
>> having a new GUC parameter to fully control it. First versions of the
>> patch did that but ISTM that it is better than enforcing the use of a
>> new feature for our user base.
>
> That's a very valid concern. But maybe it shows that
> full_page_writes=compress is not the Right Way To Do It, because then
> there's no way for the user to choose the behavior they want when
> full_page_writes=off but yet a backup is in progress. If we had a
> separate GUC, we could know the user's actual intention, instead of
> guessing.
Note that implementing a separate parameter for this patch would not
be much complicated if the core portion does not change much. What
about the long name full_page_compression or the longer name
full_page_writes_compression?
--
Michael