Re: [REVIEW] Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [REVIEW] Re: Compression of full-page-writes
Date
Msg-id CA+TgmobwTtKt8uqsEZRsWHj7scLfn1GD3fifunhn_UOcANtcBQ@mail.gmail.com
Whole thread Raw
In response to Re: [REVIEW] Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [REVIEW] Re: Compression of full-page-writes  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Xiaoyulei
Date:
Subject: Re: Many processes blocked at ProcArrayLock
Next
From: Michael Paquier
Date:
Subject: Re: [REVIEW] Re: Compression of full-page-writes