Re: fsync and semctl errors with 8.1.5/win32

Per the FAQ, we suggest that you *uninstall* your antivirus. Especially
if it has firewall-like functionality (like I beleive McAfee does). Just
disabling the scan does *not* remove the filter drivers and does not
make the antivirus not affect the database processes. So try this. If
the problem doesn't go away, look for something else installed that
might be interfernig with the normal operation of your windows install.

//Magnus

> -----Original Message-----
> From: pgsql-bugs-owner(at)postgresql(dot)org
> [mailto:pgsql-bugs-owner(at)postgresql(dot)org] On Behalf Of Jeremy Haile
> Sent: den 27 november 2006 15:21
> To: pgsql-bugs(at)postgresql(dot)org
> Subject: [BUGS] fsync and semctl errors with 8.1.5/win32
>
> I've been attempting to run PostgreSQL 8.1.5/win32 on a
> production deployment, but have started having many problems.
> McAfee Antivirus is installed and running, although I've
> excluded the entire drive where PostgreSQL is installed and
> where the data is installed.
>
> I've received several errors in the past few days/weeks.
> They fall into three general categories 1) permission denied
> errors 2) semctl errors 3) fsync errors. I am not sure how
> to reproduce these errors locally - they seem to occur at
> unpredictable intervals.
>
> The following posts seem related, although I don't see a
> resolution for any of the problems listed:
> http://www.mail-archive.com/pgsql-bugs(at)postgresql(dot)org/msg16097.html
> http://www.mail-archive.com/pgsql-bugs(at)postgresql(dot)org/msg14792.html
> http://www.mail-archive.com/pgsql-bugs(at)postgresql(dot)org/msg14916.html
>
> I have run PostgreSQL on Linux in the past and not had any
> problems. Is the win32 build generally considered stable or
> unstable for production use? Any help would be greatly appreciated!
>
> 1) PERMISSION DENIED ERROR
> This error occurred on the same day as the semctl started,
> but stopped occurring for a few hours before the semctl
> errors started.
>
> The following is an example:
> 2006-11-25 00:46:04 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:05 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:06 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:07 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:08 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:09 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:10 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:11 ERROR: could not open relation 1663/16404/84855:
> Permission denied
> 2006-11-25 00:46:12 ERROR: could not open relation 1663/16404/84855:
> Permission denied
>
>
> 2) SEMCTL ERROR
> This error occurred over and over one day with the same
> pattern - several semctl errors, then the unexpected EOF.
> This resulted in clients being unable to create database
> connections. The error occurred overnight and into the next
> day, and did not disappear until postgres was restarted.
>
> The following is an example:
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 FATAL: semctl(167238064, 15, SETVAL, 0)
> failed: A non-blocking socket operation could not be
> completed immediately.
> 2006-11-25 22:10:03 LOG: could not receive data from client:
> No connection could be made because the target machine
> actively refused it.
> 2006-11-25 22:10:03 LOG: unexpected EOF on client connection
>
>
> 3) FSYNC ERROR
> I've seen this error several times in the past - including today.
>
> The following is an example:
> 2006-11-27 00:00:20 LOG: autovacuum: processing database
> "incommDashboard"
> 2006-11-27 00:00:20 LOG: could not fsync segment 0 of relation
> 1663/16404/89952: Permission denied
> 2006-11-27 00:00:20 ERROR: storage sync failed on magnetic disk:
> Permission denied
> 2006-11-27 00:00:24 LOG: could not fsync segment 0 of relation
> 1663/16404/89952: Permission denied
> 2006-11-27 00:00:24 ERROR: storage sync failed on magnetic disk:
> Permission denied
> 2006-11-27 00:00:26 LOG: could not fsync segment 0 of relation
> 1663/16404/89952: Permission denied
> 2006-11-27 00:00:26 ERROR: storage sync failed on magnetic disk:
> Permission denied
> 2006-11-27 00:00:29 LOG: could not fsync segment 0 of relation
> 1663/16404/89952: Permission denied
> 2006-11-27 00:00:29 ERROR: storage sync failed on magnetic disk:
> Permission denied
> 2006-11-27 00:00:32 LOG: could not fsync segment 0 of relation
> 1663/16404/89952: Permission denied
> 2006-11-27 00:00:32 ERROR: storage sync failed on magnetic disk:
> Permission denied
> 2006-11-27 00:00:42 LOG: could not fsync segment 0 of relation
> 1663/16404/89952: Permission denied
> 2006-11-27 00:00:42 ERROR: storage sync failed on magnetic disk:
> Permission denied
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>