Re: [REVIEW] Re: Compression of full-page-writes
От | Michael Paquier |
---|---|
Тема | Re: [REVIEW] Re: Compression of full-page-writes |
Дата | |
Msg-id | CAB7nPqQ7QVf6gzPK9dDxzq=saRyyK8qdC5WB4cWmb_AtBLPs-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [REVIEW] Re: Compression of full-page-writes (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Dec 3, 2014 at 12:35 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Dec 2, 2014 at 7:16 PM, Michael Paquier > <michael.paquier@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
В списке pgsql-hackers по дате отправления: