BUG #16182: Error in logs from "renaming temporary statistics"

On Thu, Jan 02, 2020 at 06:55:37AM +0000, PG Bug reporting form wrote:

I have checked the permissions of the folder and files, and I can not see
why this occurs.

This error would occur on Windows when a concurrent process, external
to Postgres, has a file opened in non-shared mode while Postgres tries
to work on it. In this case the work is done by pgrename() on
Postgres side which is a custom wrapper in src/port/dirmod.c to handle
this kind of scenarios with a retry-and-sleep logic, but it gives up
after 10s (100 tries of 100ms each).

This issue could be usually caused by an antivirus or something that
scans the files of the disk where Postgres data is located. In this
case, the best thing you could do is to prevent the concurrent
activity from happening by filtering out Postgres data folder. Nobody
can guess why this file is held opened that long though without
looking at your server when the problem happens.
--
Michael

Thanks for this informative feedback. I was thinking that antivirus was an
explanation, but I am pretty sure the the PG data directory was on the
antivirus exclusion list. However, in light of this I will try to monitor
the processes that access this file and come back to you on the findings.
--
JF

On Thu, Jan 2, 2020 at 3:07 PM Michael Paquier <michael@paquier.xyz> wrote:

On Thu, Jan 02, 2020 at 06:55:37AM +0000, PG Bug reporting form wrote:

I have checked the permissions of the folder and files, and I can not see
why this occurs.

This error would occur on Windows when a concurrent process, external
to Postgres, has a file opened in non-shared mode while Postgres tries
to work on it. In this case the work is done by pgrename() on
Postgres side which is a custom wrapper in src/port/dirmod.c to handle
this kind of scenarios with a retry-and-sleep logic, but it gives up
after 10s (100 tries of 100ms each).

This issue could be usually caused by an antivirus or something that
scans the files of the disk where Postgres data is located. In this
case, the best thing you could do is to prevent the concurrent
activity from happening by filtering out Postgres data folder. Nobody
can guess why this file is held opened that long though without
looking at your server when the problem happens.
--
Michael

--
Johan Fredrik Øhman

I just wanted to add that this bug 16182 is the subject of a discussion here:

/messages/by-id/CAPpHfds9trA6ipezK3BsuuOSQwEmESiqj8pkOxACFJpoLpcoNw@mail.gmail.com

... which started in Nov 2017, and appears to be ongoing (latest message Jan 2020).

Alexander Korotkov 2017-11-28 reports that the problem occurs in the absence of antivirus etc.

Graham

At 1/3/2020 12:06 PM, =?UTF-8?Q?Johan_Fredrik_=C3=98hman?= wrote:

Looks like the mailing list mangled the URL I posted -- replacing the 'at' and 'dot' symbols. You can manually fix them, or here's better info to search for the thread:

List: pgsql-hackers
Subject: [PATCH] Atomic pgrename on Windows

Graham

At 2/13/2020 07:16 PM, Graham Wideman wrote: