Re: pg_basebackup check vs Windows file path limits

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup check vs Windows file path limits
Date: 2023-07-04 18:19:46
Message-ID: 81023744-772d-889b-99b8-bd1d58bd761b@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2023-07-03 Mo 11:18, Andrew Dunstan wrote:
>
>
> On 2023-07-03 Mo 10:16, Daniel Gustafsson wrote:
>>> On 3 Jul 2023, at 16:12, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>> I've pushed a better solution, which creates the file via a short symlink. Experimentation on fairywren showed this working.
>> The buildfarm seems a tad upset after this?
>>
>
> Yeah :-(
>
> I think it should be fixing itself now.
>
>
>

But sadly we're kinda back where we started. fairywren is failing on
REL_16_STABLE. Before the changes the failure occurred because the test
script was unable to create the file with a path > 255. Now that we have
a way to create the file the test for pg_basebackup to reject files with
names > 100 fails, I presume because the server can't actually see the
file. At this stage I'm thinking the best thing would be to skip the
test altogether on windows if the path is longer than 255.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-07-04 18:33:14 Re: Cleaning up array_in()
Previous Message Tomas Vondra 2023-07-04 18:04:40 Re: Is a pg_stat_force_next_flush() call sufficient for regression tests?