On Wed, Dec 3, 2014 at 12:35 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Dec 2, 2014 at 7:16 PM, Michael Paquier > <michael.paqu...@gmail.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers