On Mon, Oct 14, 2013 at 2:28 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Oct 10, 2013 at 9:34 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On further analysis, I found that hang occurs in some of Windows >> API(FindFirstFile, RemoveDirectroy) when symlink path >> (pg_tblspc/spcoid/TABLESPACE_VERSION_DIRECTORY) is used in these >> API's. For above testcase, it will hang in path >> destroy_tablespace_directories->ReadDir->readdir->FindFirstFile > > Well, that sucks. So it's a Windows bug. > >> Some of the ways to resolve the problem are described as below: >> >> 1. I found that if the link path is accessed as a full path during >> readdir or stat, it works fine. >> >> For example in function destroy_tablespace_directories(), the path >> used to access tablespace directory is of form >> "pg_tblspc/16235/PG_9.4_201309051" by using below sprintf >> sprintf(linkloc_with_version_dir, >> "pg_tblspc/%u/%s",tablespaceoid,TABLESPACE_VERSION_DIRECTORY); >> Now when it tries to access this path it is assumed in code that >> corresponding OS API will take care of considering this path w.r.t >> current working directory, which is right as per specs, >> however as it hangs in OS API (FindFirstFile) if path length > 130 for >> symlink and if try to use full path instead of starting with >> pg_tblspc, it works fine. >> So one way to resolve this issue is to use full path for symbolic link >> path access instead of relying on OS to use full path. > > I'm not sure how we'd implement this, except by doing #2.
If we believe it's a Windows bug, perhaps a good start would be to report it to Microsoft? There might be an "official workaround" for it, or in fact, there might already exist a fix for it.. We're *probably* going to have to end up deploying a workaround, but it would be a good idea to check first if they have a suggestion for how... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
