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

Re: Permission denied on fsync / Win32 (was right

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>
Cc: "Magnus Hagander" <mha(at)sollentuna(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Permission denied on fsync / Win32 (was right
Date: 2006-04-19 17:21:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> writes:
> Here's the evidence from this morning.  I have to admit I'm not really
> sure what to make of it though.
> ...
>   - Same pattern as Server #1.  bgwriter has a handle to the new
> relfilenode.  Other backends have a handle to either old or new.  

It seems pretty clear to me that the problem occurs when we try to
fsync the old relfilenode, which is in a pending-delete state but
hasn't been deleted yet because of the presence of open handles in
some backends.  (Peter, did you check that the error messages in
the postmaster log all refer to old relfilenodes not new ones?)

We should be able to ignore this error, but I'm certainly unwilling
to just treat EACCES in general as an ignorable error.  So the problem
is to distinguish this case from genuine permission failures.  Perhaps
ERROR_SHARING_VIOLATION should be mapped to something other than EACCES?
It seems like that's a rather poor fit.  Or we could leave the mapping
as-is and add an #ifdef'd test on GetLastError to mdsync() (ugly...)

One worry is whether there are any other possible causes of
ERROR_SHARING_VIOLATION during fsync, and if so are they all ignorable.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2006-04-19 17:28:48
Subject: Re: pg_dump or hardware?
Previous:From: Peter BrantDate: 2006-04-19 15:50:52
Subject: Re: Permission denied on fsync / Win32 (was right

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