Message-ID: <dbc00ba6-4122-43f2-9551-993665283420@dunslane.net>
Date: Mon, 8 Jul 2024 17:45:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: 010_pg_basebackup.pl vs multiple filesystems
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Dave Page <dpage@pgadmin.org>
References: <20240707070243.sb77kp4ubowauctz@awork3.anarazel.de>
 <2545bea4-9690-4922-ad77-19194fa3edd6@dunslane.net>
 <083cb3fb-4a5c-4c0e-9988-b702cc45a51f@dunslane.net>
 <20240708203157.z6y3qeyzjylacoii@awork3.anarazel.de>
From: Andrew Dunstan <andrew@dunslane.net>
Content-Language: en-US
Autocrypt: addr=andrew@dunslane.net; keydata=
 xsBNBE7KWFkBCAClridxur2AIc7eW2AR7izbfp3EnNefie2HbLF0izW5Ik5UjX2HBXBx4syI
 gY6b0ugohXrr274+baoAlvSbq6cAoQuEVrk5IZFzt20b1Xkx65FwGSEj526yiKLocqkJceSq
 Xr9xcA5SGY+FZv441chh5SU92v4q6z+6LPpoHOh97ptAVXZYNTtU0LevyvD5lja0TzbvJm6C
 eFXitJfnm1pLEr0DGJCR/iUOl/N62Kh4855zZC7NHIjQHPOvV5Stz/l5ilDhvGVk+xkXFPys
 SjZoUr1rXhYLpiyi5sR0X9FHXT0KnGuz1F5ERO7ZTLSSQ6fJwPj6gOk9K+vvoKvoeql5ABEB
 AAHNJEFuZHJldyBEdW5zdGFuIDxhbmRyZXdAZHVuc2xhbmUubmV0PsLAmwQTAQgARQIbAwIX
 gAIZAQULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUC
 ZFlxxwUJGVGAbgAKCRCZ+n/LWfw7gXikB/9ZdcUy6CTBFIIuL/bVsc1eLEW/gJBjJBF6HxNY
 xgEkAgXAp4Lg4A5U+QB9GouFr7+GYxF0BU4hzoGhNPUWltxnHdMWP8nC/38LAqgMi8L/bbsm
 HW5YPBdWYaAZAPJQVfOAgjTbRUb26KSprpyrrJKW0ZmrZfjhNPcQ72jpWzoPLQqx2X6B0fru
 1jq+cBh8lb6r1mJTim1T3JIn+F/v5VpdQS+EL8xqsHkfzKjIPsW3CIXpkypSk6saA55Rkkbl
 26AW8ftPVB0Q6Lnn6FLt9CP0MGNixBQ55yq8r1K+nCBvCCjvQjM8RDm0UUum0WNl+ifQgTLO
 E8TWEnwVtkBf+3QWzsBNBE7KWFkBCADRnOM0FCzsYW6jtncg+dWIagjUZpvaClmqn/sJluLa
 Q3v1VXMQJzYs3eC1gh386W+XBwLRpDj3jzH81lX+p73Re3d3oJW7X+ffsxuzu5ZVdMUkqBYo
 nkAbKxr6gyJ12F/+JkUVzLcoTN+d/7YsQvUVi7NaKH8mJgjz112O4fUe3p9wfAaFa0RXHc5S
 GPzRTYRRlv/XZBIho4J2tkZOnteZJZ+GbxQVlINt6fd8P6al3MWOvpP/ExJPguEfjOsO6Njy
 xjo3WfpD4lHMOR/Oc3/8mScEF84rF2jXbsFgelWnbPWAvXY+pD0dXOFRkagGmC/viwBDqq5b
 5tk76kKmUbZxABEBAAHCwHwEGAEIACYCGwwWIQTkPlhGHfx8v0RpFaWZ+n/LWfw7gQUCZFlx
 5wUJGVGAjgAKCRCZ+n/LWfw7gf+iB/4g8CPY5jihf5r/8EsoIGe2H+dpVmpPF8YGBzTIvCz/
 fQoOq8AX/pE76QEuFnFZWfjw+wgBXgCVmkox2Eflkk6z4ND3pcwGZ6CfCxTQCDk/dij+2DQ4
 6bmDCy/sBgcbz9mTpoLC11HLoPae6YN9nBNQRZDcEFEu54OaVOqlIdbA6m+POIBCXZdHOFc0
 WoDTgxHRzC1jgQNidyd6tKqcsVJs0dzF0oKTmFFmUAqTdJO12LBuNA1rlqrR3EtpYk8B/wtS
 5dIMD7Q8hwQpL+4C6GNpb6ZKnPkLi47pDOLhz2qBrqN+rqUEsT3YnExYpzj5yOBi+FlmV1Hw
 49QYe1sn2ZPs
In-Reply-To: <20240708203157.z6y3qeyzjylacoii@awork3.anarazel.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/dbc00ba6-4122-43f2-9551-993665283420%40dunslane.net>
Precedence: bulk


On 2024-07-08 Mo 4:31 PM, Andres Freund wrote:
> Hi,
>
> On 2024-07-07 09:10:48 -0400, Andrew Dunstan wrote:
>> On 2024-07-07 Su 7:28 AM, Andrew Dunstan wrote:
>>> I'll be happy to hear of one. I agree it's a mess.  Maybe we could test
>>> that the temp directory is on the same device on Windows and skip the
>>> test if not? You could still get the test to run by setting TMPDIR
>>> and/or friends.
>> Maybe we should just not try to rename the directory. Looking at the test
>> I'm pretty sure the directory should be empty. Instead of trying to move it,
>> let's just remove it, and recreate it in the tmp location.
> Good catch, yes, that'd be much better!
>
>
>> diff --git a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> index 489dde4adf..c0c334c6fc 100644
>> --- a/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> +++ b/src/bin/pg_basebackup/t/010_pg_basebackup.pl
>> @@ -363,8 +363,8 @@ my $sys_tempdir =
>> PostgreSQL::Test::Utils::tempdir_short;
>>   # Elsewhere use $tempdir to avoid file system boundary issues with moving.
>>   my $tmploc = $windows_os ? $sys_tempdir : $tempdir;
> The comment would need a bit of editing, I guess. I think we should consider
> just getting rid of the os-dependant switch now, it shouldn't be needed
> anymore?
>
>
>> -rename("$pgdata/pg_replslot", "$tmploc/pg_replslot")
>> -  or BAIL_OUT "could not move $pgdata/pg_replslot";
>> +rmtree("$pgdata/pg_replslot");
> Should this perhaps be an rmdir, to ensure that we're not removing something
> we don't want (e.g. somebody adding an earlier test for slots that then gets
> broken by the rmtree)?
>


OK, done like this.


cheers


andrew

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