Re: Permission denied on fsync / Win32 (was right sibling is not next child) - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Permission denied on fsync / Win32 (was right sibling is not next child)
Date
Msg-id 28899.1144953052@sss.pgh.pa.us
Whole thread Raw
In response to Permission denied on fsync / Win32 (was right sibling is not next child)  ("Peter Brant" <Peter.Brant@wicourts.gov>)
List pgsql-bugs
"Peter Brant" <Peter.Brant@wicourts.gov> writes:
> It turns out we've been getting rather huge numbers of "Permission
> denied" errors relating to fsync so perhaps it wasn't really a precursor
> to the crash as I'd previously thought.

> I've pasted in a complete list following this email covering the time
> span from 3/20 to 4/6.  The number in the first column is the number of
> times the given log message appeared.

Wow.  What was happening to your pg_xlog directory while this was going
on?  I would expect that the system would plow ahead after this error,
but having failed to complete the checkpoint, it would never be able to
free any back WAL segments.  Were you accumulating lots of gigabytes of
WAL files?  Or maybe the errors came and went, so that sometimes you
could get through a checkpoint?

> The interesting thing is that _none_ of the referenced relfilenode
> numbers actually appear in the file system.

Could they have been temporary tables?  Alternatively, if you routinely
use TRUNCATE, CLUSTER, or REINDEX (all of which assign new relfilenode
numbers), then maybe they were older versions of tables that still
exist.

>   - The file system is NTFS

OK, anyone know anything about permissions on NTFS?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: BUG #2390: check constraint
Next
From: "Magnus Hagander"
Date:
Subject: Re: Permission denied on fsync / Win32 (was right sibling is not next child)