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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
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-12 07:44:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

Still the probability is low, which is why I think that it would make
sense to just fix the problem on HEAD and move on.

> One little thing I noticed is the function name "RemoveXLogTempFiles".
> Other similar functions are named as RemoveOldXlogFiles or RemoveXlogFile
> (using Xlog not XLog), so it seem to me more consistent to rename this
> "RemoveXlogTempFiles" or "RemoveTempXlogFiles" and so on.

I see, a lower-case for Xlog instead of XLog. That makes sense. I have
used your second suggestion in the attached. I have also changed the
thing so as the format of the comment block is better even after


Attachment Content-Type Size
remove-xlogtemp-crash-v2.patch text/x-diff 2.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-12 07:47:27 Re: Possible bug in logical replication.
Previous Message Amit Kapila 2018-07-12 07:33:54 pgsql: Allow using the updated tuple while moving it to a different par