Temporary WAL segments files not cleaned up after an instance crash

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Temporary WAL segments files not cleaned up after an instance crash
Date: 2018-05-14 05:49:55
Message-ID: 20180514054955.GF1528@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi all,

While playing with a standby as follows I noticed that xlogtemp.*
generated in pg_wal may stay around when entering crash recovery. The
test I was conducting is pretty simple:
- Use a primary and a standby.
- Run pgbench on the primary.
- Then restart the standby with -m immediate and force WAL segment
switch on the primary in a loop. Depending on the timing, one can see
that those xlogtemp files stay around. Those files are here when
creating a new segment from scratch and append the PID of the process
creating them. Any previous file existing with the same name is
unlinked.

The problem is that if an instance is not really stable for a reason or
another and starts crash recovery periodically, then there is a risk of
accumulating those temporary files. If pg_wal is on its own partition,
tuned by max_wal_size, then there is a risk to run into ENOSPC and take
PostgreSQL down as new WAL segments cannot be created.

Shouldn't those files be cleaned up at the beginning of crash recovery?
Attached is a proposal of patch doing so.

Thoughts?
--
Michael

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2018-05-14 05:51:25 Re: Needless additional partition check in INSERT?
Previous Message Amit Langote 2018-05-14 05:29:18 Re: Incorrect comment in get_partition_dispatch_recurse