On Tue, Oct 30, 2018 at 4:15 AM Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, Oct 29, 2018 at 2:11 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > This first line looks like it might be interesting:
> >
> > LOG: could not rmdir directory
> > "base/pgsql_tmp/pgsql_tmp5088.0.sharedfileset": Directory not empty
> > ERROR: could not determine size of temporary file "0"
>
> (Thomas Munro is CC'd here.)
>
> > I suppose that this could actually just be a result of the ERROR; the
> > exact order isn't a reliable indicator of the sequence of events
> > across processes (A useful log_line_prefix setting might clear this up
> > if you collect the trace_sort output again).
>
> Hmm. So apparently Windows has a habit of setting an ENOTEMPTY errcode
> when rmdir'ing a directory that somebody merely has a handle to. It
> could just be that somebody has a Windows Explorer window open -- you
> still get ENOTEMPTY [1]! Not sure if this is truly relevant to the
> problem at hand, but it seems worth being aware of.
We only try to remove the directory after removing everything in it,
so that does seem to require a pretty strange explanation like that.
I also wondered if a worker having a handle to an unlinked file (as
permitted by the FILE_SHARE_DELETE flag we use) inside that directory
could produce that effect. Perhaps RemovedDirectoryA[1] would be
better than rmdir, since it "... marks a directory for deletion on
close. Therefore, the directory is not removed until the last handle
to the directory is closed." The documentation for rmdir[2] just says
deprecated, and _rmdir[3] mentions ENOTEMPTY, but it says you get
EACCES if someone has an open handle to the directory.
[1] https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-removedirectorya
[2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rmdir?view=vs-2017
[3] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rmdir-wrmdir?view=vs-2017
--
Thomas Munro
http://www.enterprisedb.com
