Thread: BUG #16182: Error in logs from "renaming temporary statistics"
The following bug has been logged on the website: Bug reference: 16182 Logged by: Johan Fredrik Øhman Email address: johanfo@gmail.com PostgreSQL version: 12.1 Operating system: Microsoft Windows 2019 Server Description: For some weird reason I cannot understand, I keep getting this in the logs: 2020-01-02 07:22:51.461 CET [1400] LOG: could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied 2020-01-02 07:28:31.262 CET [1400] LOG: could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied 2020-01-02 07:38:04.761 CET [1400] LOG: could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied 2020-01-02 07:44:15.785 CET [1400] LOG: could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied I have checked the permissions of the folder and files, and I can not see why this occurs. best regards JF
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
Attachment
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: 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
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: >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