Re: Long paths for tablespace leads to uninterruptible hang in Windows

On Thu, Oct 10, 2013 at 9:34 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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