Re: AdvanceXLInsertBuffer vs. WAL segment compressibility

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Date: 2016-07-23 12:25:06
Message-ID: CAA4eK1L7UvOS8TpUvoMuGZ4Mid=Mef-Cq5Q0M-2oYSHC-CSikw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jul 23, 2016 at 3:32 AM, Chapman Flack <chap(at)anastigmatix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-07-23 13:10:04 LWLocks in DSM memory
Previous Message David Rowley 2016-07-23 10:22:41 Re: bug in citext's upgrade script for parallel aggregates