Re: storage sync failed on magnetic disk: Permission denied

When the cluster performs a massive disk operations (like nightly
vacuuming or smth)
I offten got such error in log file:

2005-11-12 14:52:29 LOG: could not fsync segment 0 of relation
1663/17735/210608: Permission denied
2005-11-12 14:52:29 ERROR: storage sync failed on magnetic disk:
Permission denied
2005-11-12 14:52:30 LOG: could not fsync segment 0 of relation
1663/17735/210608: Permission denied
2005-11-12 14:52:30 ERROR: storage sync failed on magnetic disk:
Permission denied
2005-11-12 14:52:31 LOG: could not fsync segment 0 of relation
1663/17735/210608: Permission denied
2005-11-12 14:52:31 ERROR: storage sync failed on magnetic disk:
Permission denied
2005-11-12 14:52:32 LOG: could not fsync segment 0 of relation
1663/17735/210608: Permission denied
2005-11-12 14:52:32 ERROR: storage sync failed on magnetic disk:
Permission denied
2005-11-12 14:52:33 LOG: could not fsync segment 0 of relation
1663/17735/210608: Permission denied
2005-11-12 14:52:33 ERROR: storage sync failed on magnetic disk:
Permission denied
2005-11-12 14:52:34 LOG: could not fsync segment 0 of relation
1663/17735/210608: Permission denied

The error exists for a few minutes then dissapears and cluster works
normally till next time.
(actually next night ;) )
I had this situation few minutes ago on my Windows XP box and tryed to
look what was wrong with this file:
1663/17735/210608
1) File existed
2) It was locked (by somebody ??? ) during the error existance.
3) File dissapeared when the error had dissapered.
4) NTFS Permissions were set correctly.

This error was found on Windows 2000 Server SP4, Windows Proffesional and
a Windows XP HE.
On 8.0.0, 8.0.4 and 8.1 PostgreSQL servers.

Is it a windows bug?
It looked like as if somebody (not postgres) got an exclusive access to
that file.

Sorry about my english

"Valery Bondarenko" <to_undead(at)mail(dot)ru> writes:
> When the cluster performs a massive disk operations (like nightly
> vacuuming or smth)
> I offten got such error in log file:
> 2005-11-12 14:52:29 LOG: could not fsync segment 0 of relation
> 1663/17735/210608: Permission denied

> It looked like as if somebody (not postgres) got an exclusive access to
> that file.

We've heard reports of various "antivirus" products doing that sort of
thing ... what third-party software do you have installed?

regards, tom lane

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote
>> When the cluster performs a massive disk operations (like nightly
>> vacuuming or smth)
>> I offten got such error in log file:
>> 2005-11-12 14:52:29 LOG: could not fsync segment 0 of relation
>> 1663/17735/210608: Permission denied
>
>> It looked like as if somebody (not postgres) got an exclusive access to
>> that file.
>
> We've heard reports of various "antivirus" products doing that sort of
> thing ... what third-party software do you have installed?
>

The strange thing is that this time it gets an EACCESS this time. What we
get before is "Invalid Argument" message which is a mis-translation of
ERROR_SHARING_VIOLATION. Let's see what he installed ...

Regards,
Qingqing

"Valery Bondarenko" <to_undead(at)mail(dot)ru> wrote:
> Situation first occurs on _CLEAN_ Win2k server with 8.0.0 Installed by his
> installer (woops :) ).
> And it continues to...
> Also I got it in a realy "dirty" environment with 8.1.
>
> But in both cases there were no antiviruses and (AFAIK) no product which
> could do such locking.

We have a loop in pgunlink/pgrename for Win32 since it is possible that some
other processes hold the opened file (without the required flags) when we
want to drop/rename it. Here seems comes the similar situation, but not sure
the exact reason that leads to it though ... The situtation has been there
for a while, check out this thread and see if you can catch the killer (the
analysis part is bogus according to Tom):

http://archives.postgresql.org/pgsql-hackers/2005-08/msg00129.php

Regards,
Qingqing