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@mail.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@sss.pgh.pa.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 deniedIt 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@mail.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