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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

PG Bug reporting form
The following bug has been logged on the website:

Bug reference:      16182
Logged by:          Johan Fredrik Øhman
Email address:      [hidden email]
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

Reply | Threaded
Open this post in threaded view
|

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

Michael Paquier-2
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Johan Fredrik Øhman
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

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

https://www.postgresql.org/message-id/flat/CAPpHfds9trA6ipezK3BsuuOSQwEmESiqj8pkOxACFJpoLpcoNw@...#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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Graham Wideman
In reply to this post by Johan Fredrik Øhman
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@...#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