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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-19 17:21:04 | Re: Permission denied on fsync / Win32 (was right |
Previous Message | Tom Lane | 2006-04-19 14:45:48 | Re: bug in windows xp |