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. > 2. Resolve symbolic link to actual path in code whenever we tries to > access it using pgreadlink. It is already used in pg_basebackup. This seems reasonable. > 3. One another way is to check in code (initdb and create tablespace) > to not allow path of length more than 100 or 120 I don't think we could consider back-patching this, because it'd break installations that might be working fine now with longer pathnames. And I'd be a little reluctant to change the behavior in master, either, because it would create a dump-and-reload hazard, when users of older versions try to upgrade. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
