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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
