010_pg_basebackup.pl vs multiple filesystems

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Dave Page <dpage(at)pgadmin(dot)org>
Subject: 010_pg_basebackup.pl vs multiple filesystems
Date: 2024-07-07 07:02:43
Message-ID: 20240707070243.sb77kp4ubowauctz@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.

The reason for that is that github actions uses two drives, with TMP/TEMP
located on c:, the tested code on d:. This causes the following code to fail:

# Create a temporary directory in the system location.
my $sys_tempdir = PostgreSQL::Test::Utils::tempdir_short;

# On Windows use the short location to avoid path length issues.
# Elsewhere use $tempdir to avoid file system boundary issues with moving.
my $tmploc = $windows_os ? $sys_tempdir : $tempdir;

rename("$pgdata/pg_replslot", "$tmploc/pg_replslot")
or BAIL_OUT "could not move $pgdata/pg_replslot";
dir_symlink("$tmploc/pg_replslot", "$pgdata/pg_replslot")
or BAIL_OUT "could not symlink to $pgdata/pg_replslot";

It's not possible to move (vs copy) a file between two filesystems, on most
operating systems. Which thus leads to:

[23:02:03.114](0.288s) Bail out! could not move D:\a\winpgbuild\winpgbuild\postgresql-17beta2\build/testrun/pg_basebackup/010_pg_basebackup\data/t_010_pg_basebackup_main_data/pgdata/pg_replslot

This logic was added in

commit e213de8e785aac4e2ebc44282b8dc0fcc74834e8
Author: Andrew Dunstan <andrew(at)dunslane(dot)net>
Date: 2023-07-08 11:21:58 -0400

Use shorter location for pg_replslot in pg_basebackup test

and revised in

commit e9f15bc9db7564a29460d089c0917590bc13fffc
Author: Andrew Dunstan <andrew(at)dunslane(dot)net>
Date: 2023-07-08 12:34:25 -0400

Fix tmpdir issues with commit e213de8e78

The latter deals with precisely this issue, for !windows.

I've temporarily worked around this by setting TMP/TEMP to something else, but
ISTM we need a better solution.

Greetings,

Andres Freund

[1] https://www.postgresql.org/message-id/CA%2BOCxowQhMHFNRLTsXNuJpC96KRtSPHYKJuOS%3Db-Zrwmy-P4-g%40mail.gmail.com
[2] https://postgr.es/m/666ac55b-3400-fb2c-2cea-0281bf36a53c%40dunslane.net

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2024-07-07 09:42:47 report a typo in comments of ComputeXidHorizonsResult
Previous Message Andres Freund 2024-07-07 06:40:46 dropping privileges on windows vs privileged accounts