|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
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.
|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|