| From: | "Thomas H(dot)" <me(at)alternize(dot)com> |
|---|---|
| To: | "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | <pgsql-bugs(at)postgresql(dot)org>, "Magnus Hagander" <mha(at)sollentuna(dot)net> |
| Subject: | Re: BUG #2712: could not fsync segment: Permission |
| Date: | 2006-10-23 20:49:37 |
| Message-ID: | 026d01c6f6e4$c1845750$0201a8c0@iwing |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-patches |
> Actually, now that I look back in the archives, I think we had theorized
> that the fsync errors come from attempting to fsync a file that's
> already been deleted but some backend still has a reference to.
> Apparently that leads to EACCES instead of ENOENT (which the code is
> already prepared to expect).
with process explorer i can actually check which postgres.exe instance (in
all cases i've checked its just 1 instance, and always just 1 file) holds
the lock for the file in question. but will that help in determining why it
is still holding a reference?
the postgres instance that holds the lock eventually closes the filehandle
after some minutes. the process itself is not killed but continues
thereafter.
let me know if i can be of any assistance. since we do regurarly reindex one
table whose index size keeps growing despite of often vacuuming, the
fsync-problem happens almost 4-5 times per hour.
regards,
thomas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-23 20:59:22 | Re: BUG #2712: could not fsync segment: Permission |
| Previous Message | Tom Lane | 2006-10-23 19:47:14 | Re: BUG #2712: could not fsync segment: Permission |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-10-23 20:57:32 | Re: COPY does not work with regproc and aclitem |
| Previous Message | Andrew Dunstan | 2006-10-23 20:46:38 | Re: COPY does not work with regproc and aclitem |