From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Suraj Kharage <suraj.kharage@enterprisedb.com>
Cc: tushar <tushar.ahuja@enterprisedb.com>
Cc: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>
Cc: Tels <nospam-pg-abuse@bloodgate.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Jeevan Chalke <jeevan.chalke@enterprisedb.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Subject: Re: backup manifests and contemporaneous buildfarm failures
Date: Wed, 8 Apr 2020 13:45:39 -0400
Message-ID: <7330a7c7-ce5f-9769-39a1-bdb0b32bb4a6@2ndQuadrant.com> (raw)
In-Reply-To: <CAA8=A7-FFbnpVGg5-T-tvNLhLN_XkD6yGpJ9VHKqsROiHnsFFw@mail.gmail.com>
References: <CA+TgmoazJ5wh+H77kjVfMnDh6WLh=oJodrwJ21SACSq5fojwPg@mail.gmail.com>
<20200403205412.GA8279@alvherre.pgsql>
<CA+TgmoaRbm-L1C2YkDVPx1TGN9ufxWjnaweTwKE=TQC-YOD=rg@mail.gmail.com>
<CA+TgmoZ4bAbjd_Am=UiMpBrgPEO=7YarqvaAMrQYKP1GkkOaRg@mail.gmail.com>
<alpine.DEB.2.21.2004032346550.16227@pseudo>
<22394.1585951968@sss.pgh.pa.us>
<CA+Tgmoah0khUqHG5vn8k=LJFO0mmNLyM3HtUmh4RBkq7W2GFgQ@mail.gmail.com>
<3419.1585965125@sss.pgh.pa.us>
<CA+TgmoYR6GKr1kc4KTBwXbNChDaJX8qnx7k+KKgtNnSiFgCumA@mail.gmail.com>
<CA+TgmoaUOS5X64nKgFxNV7JHN4sRkNAJYW2gHz-LMb0Ej4xHig@mail.gmail.com>
<24829.1586234244@sss.pgh.pa.us>
<CAA8=A7-FFbnpVGg5-T-tvNLhLN_XkD6yGpJ9VHKqsROiHnsFFw@mail.gmail.com>
On 4/7/20 9:42 AM, Andrew Dunstan wrote:
> On Tue, Apr 7, 2020 at 12:37 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Taking stock of the situation this morning, most of the buildfarm is
>>> now green. There are three failures, on eelpout (6 hours ago),
>>> fairywren (17 hours ago), and hyrax (3 days, 7 hours ago).
>> fairywren has now done this twice in the pg_validatebackupCheck step:
>>
>> exec failed: Bad address at /home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/test/perl/TestLib.pm line 340.
>> at /home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/test/perl/TestLib.pm line 340.
>>
>> I'm a tad suspicious that it needs another perl2host()
>> somewhere, but the log isn't very clear as to where.
>>
>> More generally, I wonder if we ought to be trying to
>> centralize those perl2host() calls instead of sticking
>> them into individual test cases.
>>
>>
>
> Not sure about that. I'll see if I can run it by hand and get some
> more info. What's quite odd is that jacana (a very similar setup) is
> passing this happily.
>
OK, tricky, but here's what I did to get this working on fairywren.
First, on Msys2 there is a problem with name mangling. We've had to fix
this before by telling it to ignore certain argument prefixes.
Second, once that was fixed rmdir was failing on the tablespace. On
Windows this is a junction, so unlink is the correct thing to do, I
believe, just as it is on Unix where it's a symlink.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:fix_validate_regression.patch (text/x-patch, 1.4K) downloaddiff --git a/src/bin/pg_validatebackup/t/003_corruption.pl b/src/bin/pg_validatebackup/t/003_corruption.plindex 7a09d02e6c..fe717dfc73 100644--- a/src/bin/pg_validatebackup/t/003_corruption.pl+++ b/src/bin/pg_validatebackup/t/003_corruption.pl@@ -16,6 +16,8 @@ $master->start;
# Include a user-defined tablespace in the hopes of detecting problems in that
# area.
my $source_ts_path = TestLib::perl2host(TestLib::tempdir_short());
+my $source_ts_prefix = $source_ts_path;+$source_ts_prefix =~ s!([^A-Z]:/[^/]*)/.*!$1!;
$master->safe_psql('postgres', <<EOM);
CREATE TABLE x1 (a int);
INSERT INTO x1 VALUES (111);
@@ -105,6 +107,7 @@ for my $scenario (@scenario)
# Take a backup and check that it validates OK.
my $backup_path = $master->backup_dir . '/' . $name;
my $backup_ts_path = TestLib::perl2host(TestLib::tempdir_short());
+ local $ENV{MSYS2_ARG_CONV_EXCL} = $source_ts_prefix;
$master->command_ok(['pg_basebackup', '-D', $backup_path, '--no-sync',
'-T', "${source_ts_path}=${backup_ts_path}"],
"base backup ok");
@@ -177,14 +180,7 @@ sub mutilate_missing_tablespace
my ($tsoid) = grep { $_ ne '.' && $_ ne '..' }
slurp_dir("$backup_path/pg_tblspc");
my $pathname = "$backup_path/pg_tblspc/$tsoid";
- if ($windows_os)- {- rmdir($pathname) || die "$pathname: $!";- }- else- {- unlink($pathname) || die "$pathname: $!";- }+ unlink($pathname) || die "$pathname: $!";
return;
}
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andrew.dunstan@2ndquadrant.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, coelho@cri.ensmp.fr, alvherre@2ndquadrant.com, david@pgmasters.net, andres@anarazel.de, noah@leadboat.com, sfrost@snowman.net, amit.kapila16@gmail.com, suraj.kharage@enterprisedb.com, tushar.ahuja@enterprisedb.com, rajkumar.raghuwanshi@enterprisedb.com, rushabh.lathia@gmail.com, nospam-pg-abuse@bloodgate.com, jeevan.chalke@enterprisedb.com, vignesh21@gmail.com, thomas.munro@gmail.com
Subject: Re: backup manifests and contemporaneous buildfarm failures
In-Reply-To: <7330a7c7-ce5f-9769-39a1-bdb0b32bb4a6@2ndQuadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox