Re: wal_segment size vs max_wal_size

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: wal_segment size vs max_wal_size
Date: 2016-09-26 11:34:14
Message-ID: CAA4eK1+LUCgQ2yjVKrndTGLNLt6XxuRH8dnKnR64=L+kwYGBYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 26, 2016 at 4:00 PM, Kuntal Ghosh
<kuntalghosh(dot)2007(at)gmail(dot)com> wrote:
> On Wed, Sep 21, 2016 at 8:33 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> There is apparently some misbehavior if max_wal_size is less than 5 *
>> wal_segment_size.
>>
>
>> This should probably be made friendlier in some way. But it also shows
>> that bigger WAL segment sizes are apparently not well-chartered
>> territory lately.
>>
> Well, there can be multiple solutions to this problem.
> 1. If somebody intends to increase wal segment size, he should
> increase max_wal_size accordingly.
> 2. In recovery test, we can add some delay before taking backup so
> that the pending logs in the buffer
> gets flushed. (Not a good solution)
> 3. In CreateRestartPoint() method, we can force a XLogFlush to update
> minRecoveryPoint.
>

IIRC, there is already a patch to update the minRecoveryPoint
correctly, can you check if that solves the problem for you?

[1] - https://www.postgresql.org/message-id/20160609.215558.118976703.horiguchi.kyotaro%40lab.ntt.co.jp

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeevan Chalke 2016-09-26 11:50:31 Re: Add support for restrictive RLS policies
Previous Message Fabien COELHO 2016-09-26 11:27:10 Re: pgbench - allow to store select results into variables