Re: BUG #2712: could not fsync segment: Permission - Mailing list pgsql-bugs

From Thomas H.
Subject Re: BUG #2712: could not fsync segment: Permission
Date
Msg-id 0ab701c6f9d4$850a1010$6501a8c0@iwing
Whole thread Raw
In response to Re: BUG #2712: could not fsync segment: Permission  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-bugs
> It might be interesting to think about not requiring the ControlFileLock
> to be held while making new WAL segments.  I think the only reason it
> does that is to ensure that link/rename failure can be treated as a hard
> error (because no one could have beat us to the filename), but we're
> already having to back off that stance for Windows ...

on a sidenote, i was able to work around the total xlog-lock by ingreasing
checkpoint_segments from 3 (default) to 12. that seems enough to have the
processes release (timeout?) the filehandles before writer-process wants to
rename the xlog file, at least under normal workload. if there is a data
load, the lockup still happens, but i can live with that for now.

the logs are still being swamped with the other delete error messages, tho:

2006-10-27 16:16:58 [5828] ERROR:  XX000: storage sync failed on magnetic
disk: Permission denied
2006-10-27 16:16:58 [5828] LOCATION:  smgrsync, smgr.c:888
2006-10-27 16:16:59 [5828] LOG:  42501: could not fsync segment 0 of
relation 1663/3964774/6495380: Permission denied
2006-10-27 16:16:59 [5828] LOCATION:  mdsync, md.c:785
2006-10-27 16:16:59 [5828] ERROR:  XX000: storage sync failed on magnetic
disk: Permission denied
2006-10-27 16:16:59 [5828] LOCATION:  smgrsync, smgr.c:888

magnus, where you able to do a debug build for me to test the patch? would
be nice if a solution could be found for the final 8.2 release.

cheers,
thomas

pgsql-bugs by date:

Previous
From: "Alexey Zayats"
Date:
Subject: BUG #2724: Could not check connection status with "ssl=on"
Next
From: Tom Lane
Date:
Subject: Re: BUG #2724: Could not check connection status with "ssl=on"