Re: AdvanceXLInsertBuffer vs. WAL segment compressibility - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Date
Msg-id CAA4eK1L7UvOS8TpUvoMuGZ4Mid=Mef-Cq5Q0M-2oYSHC-CSikw@mail.gmail.com
Whole thread Raw
In response to AdvanceXLInsertBuffer vs. WAL segment compressibility  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: AdvanceXLInsertBuffer vs. WAL segment compressibility  (Chapman Flack <chap@anastigmatix.net>)
List pgsql-hackers
On Sat, Jul 23, 2016 at 3:32 AM, Chapman Flack <chap@anastigmatix.net> wrote:
>
> Would it then be possible to go back to the old behavior (or make
> it selectable) of not overwriting the full 16 MB every time?
>

I don't see going back to old behaviour is an improvement, because as
as you pointed out above that it helps to improve the compression
ratio of WAL files for tools like gzip and it doesn't seem advisable
to loose that capability.  I think providing an option to select that
behaviour could be one choice, but use case seems narrow to me
considering there are tools (pglesslog) to clear the tail.  Do you
find any problems with that tool which makes you think that it is not
reliable?

> Or did the 9.4 changes also change enough other logic that stuff
> would now break if that isn't done?
>

The changes related to the same seems to be isolated (mainly in
CopyXLogRecordToWAL()) and doesn't look to impact other parts of
system, although some more analysis is needed to confirm the same, but
I think the point to make it optional doesn't seem convincing to me.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: bug in citext's upgrade script for parallel aggregates
Next
From: Thomas Munro
Date:
Subject: LWLocks in DSM memory