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: | Raw Message | Whole Thread | 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 |