Thread: 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 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@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