Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sQv1p-00CKZr-1X for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jul 2024 20:32:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sQv1n-0091q2-MS for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Jul 2024 20:32:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sQv1n-0091pu-D3 for pgsql-hackers@lists.postgresql.org; Mon, 08 Jul 2024 20:32:03 +0000 Received: from fhigh2-smtp.messagingengine.com ([103.168.172.153]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sQv1k-0015er-IQ for pgsql-hackers@postgresql.org; Mon, 08 Jul 2024 20:32:02 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 038601140329; Mon, 8 Jul 2024 16:32:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 08 Jul 2024 16:32:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1720470719; x=1720557119; bh=pDqrVqdjdoZGOLhXQSek1bEoXtCvfblprSZa15neSuI=; b= FiNBOa2S+8euzlbEdSkJMRNkxMPfCeYlNlNmo8vaXB3swmIiDv3czbMNy5A4/G2I vI+KHDH8YsemfkmWsBWIuwgEtrlkaTAfI5qbJfvu+Iow7rnRUVtNrhg6fCFa62i6 1Oc7gmLczDw48qpAkQJZ1ixQRYKVBZZAHtBUmgmt9Cl//OrXJqP0aC6VyoJZipbC qMurkQYE7cvoztuYWPzzYyvtFgVLSUwTCul1AC063i87JJQ3WLnL5nvGjyKl8hRJ +gdHcHB3/M+850wFnzOWRoNKLN0mvKThCvjD23cGc3zbANllgXOxMBB2JxvXlocF NgFNaZq3gkPmQcDirUeDZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1720470719; x= 1720557119; bh=pDqrVqdjdoZGOLhXQSek1bEoXtCvfblprSZa15neSuI=; b=W waeRLeRRKdKY0W8TLA46Tw1zsbgaBi4AhYlc7sDDMoDo7F275DI1CBV/30JBBZdf FPLABle18ZjW/u3Cte7f3JjAzM0rGkw08U7o/SdUQaeYKZ+B2HbKsCI6jRAXZMn+ TBGiPYwFgFUqqiubu0WSGdbPe/3vvXRr8UJfkoIuk34E7iw7pHfJDXqCO6eJBj4p fqh5PaYevMlv51YwzgGVe0IwALbY2Omc+Fca1/p/FFjwRms+sfKWW3QocjUc/Gsl BIvoUCPCS16zAc8BQ3irxjkUaSVMpT6InPnqZjD5XRWnzCheA5lv1kvvVYo6gJgx lHAh9HKPuMNfuoDl9jqjw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggugfgjsehtkeertddttddunecuhfhrohhmpeetnhgu rhgvshcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtf frrghtthgvrhhnpedutdeigeeljeehueejieevgeeulefhkeelueffudekudeludffheff gfetieevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 8 Jul 2024 16:31:58 -0400 (EDT) Date: Mon, 8 Jul 2024 13:31:57 -0700 From: Andres Freund To: Andrew Dunstan Cc: pgsql-hackers@postgresql.org, Dave Page Subject: Re: 010_pg_basebackup.pl vs multiple filesystems Message-ID: <20240708203157.z6y3qeyzjylacoii@awork3.anarazel.de> References: <20240707070243.sb77kp4ubowauctz@awork3.anarazel.de> <2545bea4-9690-4922-ad77-19194fa3edd6@dunslane.net> <083cb3fb-4a5c-4c0e-9988-b702cc45a51f@dunslane.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <083cb3fb-4a5c-4c0e-9988-b702cc45a51f@dunslane.net> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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)? Greetings, Andres Freund