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-19 15:50:52
Message-ID: 4446160C020000BE00002FC6@gwmta.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
Here's the evidence from this morning.  I have to admit I'm not really
sure what to make of it though.

Pete

The fsync / Permission denied errors occurred on 2 of 3 active servers
for the 7 am CLUSTER cycle.

Server #1 (with fsync errors):
  - Both old and new relfilenodes are still visible with a 'dir':
04/19/2006  07:00 AM            16,384 1532868
04/19/2006  07:06 AM             8,192 1536650

  - postgres.exe processes have handles to both old and new
relfilenodes

#1:
  F64: File          G:\pgsql\data\base\16385\1532868
  F84: Event         \BaseNamedObjects\pgident: postgres: bigbird
bigbird 127.0.0.1(1745) idle

#2:
  F80: File          G:\pgsql\data\base\16385\1536650
  AB4: Event         \BaseNamedObjects\pgident: postgres: writer
process

#3:
  F0C: File          G:\pgsql\data\base\16385\1536650
  F48: Event         \BaseNamedObjects\pgident: postgres: bigbird
bigbird 127.0.0.1(1732) idle

(plus a few more like this)

Server #2 (with fsync errors):
  - Same pattern as Server #1.  bgwriter has a handle to the new
relfilenode.  Other backends have a handle to either old or new.  

Server #3 (w/o fsync errors):
  - Only the new relfilenode is visible with a 'dir':
04/19/2006  07:34 AM            16,384 1550915

  - postgres.exe processes have handles to both old and new
relfilenodes

#1:
  F60: File          G:\pgsql\data\base\16385\1547888
  F84: Event         \BaseNamedObjects\pgident: postgres: bigbird
bigbird 127.0.0.1(4060) idle

(plus two more like this)

#2:
  F78: File          G:\pgsql\data\base\16385\1550915
  F84: Event         \BaseNamedObjects\pgident: postgres: bigbird
bigbird 127.0.0.1(2925) idle

(plus two more like this)


>>> "Magnus Hagander" <mha(at)sollentuna(dot)net> 04/18/06 9:00 pm >>>
> It happens often enough and the episodes last long enough 
> that grabbing a handle dump while this is going on should be 
> easily done.
> 
> Regarding the Win32 error code, backend/storage/file/fd.c 
> calls _commit(). 
> http://msdn2.microsoft.com/en-us/library/17618685(VS.80).aspx 
>   It looks
> like it is already using errno to report errors.  Will 
> GetLastError() return something useful there?

Good point.
Ran a quick test. If I open the file read-only and then fsync, I get
errno=9 (EBADF) and GetLastError()=5.  Which explains the fact that we
got the wrong error-code. The *underlying API call* to _commit()
returns
access denied...

Looking at the source to _commit(), if the call to FlushFileBuffers()
returns an error, it will set _doserrno to that value,and then return
with errno=EBADF.

So, this basicalliyu means that FlushFileBuffers() returns ACCESS
DENIED.

//Magnus

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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2006-04-19 17:21:04
Subject: Re: Permission denied on fsync / Win32 (was right
Previous:From: Tom LaneDate: 2006-04-19 14:45:48
Subject: Re: bug in windows xp

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