On 16/02/2021 12:23 am, Thorsten Schöning wrote:
The mystery now is that the only process logged as touching the
affected WAL files is postgres.exe (of which there are many separate
processes). Could it be that one of the postgres.exe instances is
holding the affected WAL files in use after another postgres.exe
instance has flagged the file as deleted?[...]
I suggest checking your WAL-related and archive/backup settings for
Postgres again. There's e.g. "archive_command" optionally copying WALs
to some other place and postgres.exe would wait until that process has
finished, maybe locking the file to copy itself as well. Or
"archive_timeout" interfering with some other operations or alike.
Thanks Thorsten. The WAL archive settings are out-of-the-box defaults,
i.e. disabled: archive_mode = off; archive_command = ''; archive_timeout
= 0.
I'm not sure there is anything else I can check at this time. The good
thing is it doesn't seem to cause any problem other than logging "could
not rename file" warnings, so I might have to park this for now. If I
find anything else that might offer a new lead I will report back.
Kind regards,
Guy
