Reputation: 71
If you ever run out of space in your pg_wal
directory, and you can't grow the size of that directory or switch to standby in a case where your primary goes down as a result of the full pg_wal directory, when moving the WAL files to a different location, ensure not to move pg_wal/00000003.history
as it is a core file when starting pg_basebackup for streaming replication. If in case you had moved the file already to a different location, consider bringing this particular one pg_wal/00000003.history
back to the pg_wal
directory.
In a case where you had actually deleted the file then you may consider just creating another to see if will work...i have not tried it myself so you maybe the first or second to try :).
I faced this issue in my production environment and resolved it by copying back pg_wal/00000003.history
from where i had copied it to and my streaming replication could run without errors.
Upvotes: 0
Views: 3724
Reputation: 247865
Never, ever, manually mess with the contents of pg_wal
. In v10, we went to some effort to rename what was formerly known as pg_xlog
to pg_wal
, precisely to discourage misguided people who thought that were "just log files" from deleting files there.
If you run out of space, there is one thing you can do: move the entire pg_wal
to a different file system where you have space and put a symbolic link to the new location into the PostgreSQL data directory.
Upvotes: 2