Skip site navigation (1) Skip section navigation (2)

Re: Permission denied on fsync / Win32 (was right

From: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>
To: <Magnus Hagander <mha(at)sollentuna(dot)net>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Permission denied on fsync / Win32 (was right
Date: 2006-04-13 20:17:18
Message-ID: 443E6B7E020000BE00002D85@gwmta.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
The culprit is CLUSTER.  There is a batch file which runs CLUSTER
against six, relatively small (60k rows between them) tables at 7am,
1pm, and 9pm.  Follows is the list of dates and hours when the
"Permission denied" errors showed up.  They match up to a tee (although
the error apparently sometimes persists for a while).

The machine is clean (basically just Windows + Postgres [no AV,
firewall, etc. software]).

Pete

2006-03-20 21
2006-03-21 07
2006-03-22 21
2006-03-23 21
2006-03-23 22
2006-03-24 13
2006-03-24 21
2006-03-24 22
2006-03-26 13
2006-03-27 13
2006-03-27 21
2006-03-27 22
2006-03-28 13
2006-03-28 21
2006-03-29 13
2006-03-29 21
2006-03-30 13
2006-03-30 14
2006-03-30 15
2006-03-30 21
2006-03-30 22
2006-03-31 07
2006-03-31 08
2006-03-31 09
2006-03-31 10
2006-03-31 11
2006-03-31 12
2006-03-31 13
2006-04-03 21
2006-04-04 07
2006-04-05 07
2006-04-05 21


>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 04/13/06 8:30 pm >>>
> 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.


In response to

Responses

pgsql-bugs by date

Next:From: Dave PageDate: 2006-04-13 20:38:01
Subject: Re: BUG #2386: pg_restore doesn't restore large objects
Previous:From: Bruce MomjianDate: 2006-04-13 19:39:47
Subject: Re: BUG #2386: pg_restore doesn't restore large objects

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group