From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com>, 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-11-11 15:18:51 |
Message-ID: | 9293e623-1d5e-0bd3-9b61-6129821b6f42@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi, Alexander
On 2023-11-11 Sa 08:00, Alexander Lakhin wrote:
> Hello Andrew,
>
> 08.07.2023 18:52, Andrew Dunstan wrote:
>>> Since this test is passing on HEAD which has slightly shorter paths, I'm wondering if we should change this:
>>>
>>> rename("$pgdata/pg_replslot", "$tempdir/pg_replslot")
>>> or BAIL_OUT "could not move $pgdata/pg_replslot";
>>> dir_symlink("$tempdir/pg_replslot", "$pgdata/pg_replslot")
>>> or BAIL_OUT "could not symlink to $pgdata/pg_replslot";
>>>
>>> to use the much shorter $sys_tempdir created a few lines below.
>>>
>> Pushed a tested fix along those lines.
>>
>
> Today I've started up my Windows VM to run some tests and discovered a
> test
> failure caused by that fix (e213de8e7):
> >meson test
> Ok: 246
> Expected Fail: 0
> Fail: 1
> Unexpected Pass: 0
> Skipped: 14
> Timeout: 0
>
> ...\010_pg_basebackup\log\regress_log_010_pg_basebackup.txt contains:
> [04:42:45.321](0.291s) Bail out! could not move
> T:\postgresql\build/testrun/pg_basebackup/010_pg_basebackup\data/t_010_pg_basebackup_main_data/pgdata/pg_replslot
>
> With a diagnostic print added before rename() in 010_pg_basebackup.pl,
> I see:
> rename("T:\postgresql\build/testrun/pg_basebackup/010_pg_basebackup\data/t_010_pg_basebackup_main_data/pgdata/pg_replslot",
> "C:\Users\User\AppData\Local\Temp\fGT76tZUWr/pg_replslot")
> That is, I have the postgres source tree and the user tempdir placed on
> different disks.
>
> perldoc on rename() says that it usually doesn't work across filesystem
> boundaries, so I think it's not a Windows-specific issue.
>
>
Hmm, maybe we should be using File::Copy::move() instead of rename().
The docco for that says:
If possible, move() will simply rename the file. Otherwise, it
copies the file to the new location and deletes the original. If an
error occurs during this copy-and-delete process, you may be left
with a (possibly partial) copy of the file under the destination
name.
Can you try it out?
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-11-11 15:49:37 | Re: Making auto_explain more useful / convenient |
Previous Message | Alexander Lakhin | 2023-11-11 13:00:00 | Re: pg_basebackup check vs Windows file path limits |