| Author |
storage sync failed on magnetic disk: Permission denied
|
|
| Valery Bondarenko 2005-11-12, 9:24 am |
|
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
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Tom Lane 2005-11-12, 11:23 am |
| "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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly
| |
| Qingqing Zhou 2005-11-12, 1:23 pm |
|
"Tom Lane" <tgl@sss.pgh.pa.us> wrote
>
>
> 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_VIOLAT
ION. Let's see what he installed ...
Regards,
Qingqing
| |
| Qingqing Zhou 2005-11-12, 8:23 pm |
| "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/pgsq...08/msg00129.php
Regards,
Qingqing
|
|
|
|