I just wanted to add that this bug 16182 is the subject of a discussion here:
https://www.postgresql.org/message-id/flat/CAPpHfds9trA6ipezK3BsuuOSQwEmESiqj8pkOxACFJpoLpcoNw@mail.gmail.com#9b04576b717175e9dbf03cc991977d3f
... 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:
>--0000000000003cddfd059b41d8e9
>Content-Type: text/plain; charset="UTF-8"
>Content-Transfer-Encoding: quoted-printable
>
>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 s=
>ee
>> > 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
>>
>
>
>--=20
>Johan Fredrik =C3=98hman
