Re: Temporary WAL segments files not cleaned up after an instance crash

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Temporary WAL segments files not cleaned up after an instance crash
Date: 2018-07-13 09:50:55
Message-ID: 20180713185055.2d74cb8a.nagata@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 12 Jul 2018 16:44:45 +0900
Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Thu, Jul 12, 2018 at 03:35:53PM +0900, Yugo Nagata wrote:
> > I think it makes sense to remove unnecessary temporary WAL files although
> > I'm not sure how high the risk of ENOSPC is.
>
> It depends on how close to the partition size limit max_wal_size is set,
> and how much a system is unstable. Switching on/off a VM where Postgres
> is located can participate in that, as well as VM snapshots taken
> without memory (I work a lot on those as you can guess :D). Setting it
> to 70% of the partition size is what I imagine is the base, but I can
> imagine as well people setting it at 90% or more.

Thank you for your explaining this. I have understood the problem
you concern well.

Thanks,

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 李海龙 2018-07-13 10:09:20 function lca('{}'::ltree[]) caused DB Instance crash
Previous Message Yugo Nagata 2018-07-13 09:45:02 Re: Problem on pg_dump RANGE partition with expressions