FindFirstFile can take a wildcard filename
pattern. It appears that we are effectively
calling FindFirstFile without a pattern, getting
all 56000 file names with complete stat
information, doing a poor-man's regex on
those names, and matching just the temporary
files.
If RemovePgTempFiles were modified to
pass a filter, this code might perform better
on Windows. I'll look into this.
From: Tom Lane <tgl@xxxxxxxxxxxxx>
To: Mark Dilger <markdilger@xxxxxxxxx>
Cc: deepak <deepak.pn@xxxxxxxxx>; Alban Hertroys <haramrae@xxxxxxxxx>; "pgsql-general@xxxxxxxxxxxxxx" <pgsql-general@xxxxxxxxxxxxxx>
Sent: Wednesday, May 23, 2012 4:25 PM
Subject: Re: FATAL: lock file "postmaster.pid" already exists
Mark Dilger <markdilger@xxxxxxxxx> writes:
> I am running this code on Windows 2003. It
> appears that postgres has in src/port/dirent.c
> a port of readdir() that internally uses the
> WIN32_FIND_DATA structure, and the function
> FindNextFile() to iterate through the directory.
> Looking at the documentation, it seems that
> this function does collect file creation time,
> last access time, last write time, file size, etc.,
> much like performing a stat.
> In my case, the code is iterating through roughly
> 56,000 files. Apparently, this is doing the
> equivalent of a stat on each of them.
That would explain it all right. I think you're basically screwed here,
because so far as I can see Windows doesn't provide any means to
enumerate a directory's contents without fetching that info; at least
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364232(v=vs.85).aspx
doesn't seem to offer any substitutes for FindFirstFile/FindNextFile.
It's barely possible that using FindFirstFileEx with fInfoLevelId =
FindExInfoBasic would save enough to be useful, except that that option
doesn't exist on Windows 2003 anyway.
Consider using another operating system ...
regards, tom lane
