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

"Valery Bondarenko" <to_undead (AT) mail (DOT) ru> writes:
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 (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

"Tom Lane" <tgl (AT) sss (DOT) pgh.pa.us> wrote
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



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

"Valery Bondarenko" <to_undead (AT) mail (DOT) ru> wrote:
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...8/msg00129.php


Regards,
Qingqing



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings