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

From Amit Kapila
Subject Re: Long paths for tablespace leads to uninterruptible hang in Windows
Date
Msg-id CAA4eK1LJeeJSWNVuCR_z1uWYBbKVXU8_GgXG5VgWh_YO=oKPaA@mail.gmail.com
Whole thread Raw
In response to Re: Long paths for tablespace leads to uninterruptible hang in Windows  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Long paths for tablespace leads to uninterruptible hang in Windows  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Feb 14, 2014 at 8:27 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Jan  7, 2014 at 12:33:33PM +0530, Amit Kapila wrote:
>> On Thu, Oct 31, 2013 at 8:58 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> > On Wed, Oct 16, 2013 at 1:44 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> >> On Tue, Oct 15, 2013 at 6:28 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> >>> 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?
>>
>> Further update on this issue:
>>
>> Microsoft has suggested a workaround for stat API. Their suggestion
>> is to use 'GetFileAttributesEx' instead of stat, when I tried their
>> suggestion, it also gives me same problem as stat.
>>
>> Still they have not told anything about other API's
>> (rmdir, RemoveDirectory) which has same problem.
>
> Where are we on this?

Till now we didn't received any workaround which can fix this problem
from Microsoft. From the discussion over support ticket with them,
it seems this problem is in their kernel and changing the code for
it might not be straight forward for them, neither they have any clear
alternative.

> Is there a check we should add in our code?

We can possibly solve this problem in one of the below ways:

1. Resolve symbolic link to actual path in code whenever we tries to
access it.

2. Another way is to check in code (initdb and create tablespace)
to not allow path of length more than ~120 for Windows.

Approach-1 has benefit that it can support the actual MAX_PATH and
even if MS doesn't resolve the problem, PostgreSQL will not face it.

Approach-2 is straightforward to fix. If we want to go with Approach-2,
then we might change the limit of MaxPath for windows in future
whenever there is a fix for it.


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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Small psql memory fix
Next
From: Hiroshi Inoue
Date:
Subject: Re: narwhal and PGDLLIMPORT