Re: Long paths for tablespace leads to uninterruptible hang in Windows - Mailing list pgsql-hackers

On Wed, Oct 16, 2013 at 2:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Oct 15, 2013 at 4:14 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Tue, Oct 15, 2013 at 6:28 PM, Magnus Hagander <magnus@hagander.net> wrote:
>>> On Tue, Oct 15, 2013 at 2:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>>> On Mon, Oct 14, 2013 at 1:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>>>> Well, that sucks.  So it's a Windows bug.
>>>>>
>>>>> It's not clear to me that we should do anything about this at all,
>>>>> except perhaps document that people should avoid long tablespace
>>>>> path names on an unknown set of Windows versions.  We should not
>>>>> be in the business of working around any and every bug coming out
>>>>> of Redmond.
>>>>
>>>> It's sort of incomprehensible to me that Microsoft has a bug like this
>>>> and apparently hasn't fixed it.  But I think I still favor trying to
>>>> work around it.  When people try to use a long data directory name and
>>>> it freezes the system, some of them will blame us rather than
>>>> Microsoft.  We've certainly gone to considerable lengths to work
>>>> around extremely strange bugs in various compiler toolchains, even
>>>> relatively obscure ones.  I don't particularly see why we shouldn't do
>>>> the same here.
>>>
>>> I agree we'll probably want to work around it in the end, but I still
>>> think it should be put to Microsoft PSS if we can. The usual - have we
>>> actually produced a self-contained example that does just this (and
>>> doesn't include the full postgres support) and submitted it to
>>> *microsoft* for comments?
>>
>>   I have written a self contained win32 console application with which
>> the issue can be reproduced.
>>   The application project is attached with this mail.
>>
>>   Here is brief description of the project:
>>   This project is created using MSVC 2010, but even if somebody
>> doesn't have this version of VC, functions in file long_path.cpp can
>> be copied and
>>   used in new project.
>>   In project settings, I have changed Character Set to "Use Multi-Byte
>> Character Set" which is what Postgres uses.
>>
>>   It takes 3 parameters as input:
>>   existingpath - path for which link will be created. this path should
>> be an already
>>                       existing path with one level less than actual
>> path. For example,
>>                       if we want to create a link for path
>> "E:/PG_Patch/Long_Path/path_dir/version_dir",
>>               then this should be "E:/PG_Patch/Long_Path/path_dir".
>>   newpath      - path where link needs to be created. it should be
>> non-absolute path
>>                       of format "linked_path_dir/test_version"
>>   curpath       - path to set as current working directory path, it
>> should be the
>>                       location to prepend to newpath
>>
>>  Currently I have used input parameters as
>>  E:/PG_Patch/Long_Path/path_dir
>>  linked_path_dir/test_version
>>
E:/PG_Patch/Long_Path/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>>
>>  Long path is much less than 260 char limit on windows, I have
>> observed this problem with path length > 130 (approx.)
>
> And this reliably reproduces the hang?
  Yes, it produces hang whenever the length of 'curpath' parameter is
greater then 130 (approx.). In above example, I used curpath of length
159.

> On which Windows version(s)?
  I used Windows 7 64bit to reproduce it. However the original user
has reported this issue on Windows 2008 64bit, so this application
should hang on other Windows 2008 64bit as well.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com