From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: pgsql-hackers@postgresql.org, Fabien COELHO <coelho@cri.ensmp.fr>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        David Steele <david@pgmasters.net>,
        "Bossart,
    Nathan" <bossartn@amazon.com>,
        Thomas Munro <thomas.munro@gmail.com>
Subject: Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at
 end-of-transaction
In-reply-to: <20200317020017.GT26184@telsasoft.com>
References: <20200308173103.GC1357@telsasoft.com>
 <27334.1583692669@sss.pgh.pa.us> <20200308191456.GD1357@telsasoft.com>
 <5679.1583696409@sss.pgh.pa.us> <20200311111921.GQ29065@telsasoft.com>
 <21724.1583955158@sss.pgh.pa.us> <20200312121156.GB29065@telsasoft.com>
 <20200316155306.GM26184@telsasoft.com> <3061.1584409130@sss.pgh.pa.us>
 <20200317020017.GT26184@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Mon, 16 Mar 2020 21:00:17 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <24243.1585415634.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 28 Mar 2020 13:13:54 -0400
Message-ID: <24244.1585415634@sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> Thanks for fixing my test case and pushing.

The buildfarm just showed up another instability in the test cases
we added:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D regression.diffs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
diff -U3 /home/bf/build/buildfarm-idiacanthus/HEAD/pgsql.build/../pgsql/sr=
c/test/regress/expected/misc_functions.out /home/bf/build/buildfarm-idiaca=
nthus/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/regress/results/misc_f=
unctions.out
--- /home/bf/build/buildfarm-idiacanthus/HEAD/pgsql.build/../pgsql/src/tes=
t/regress/expected/misc_functions.out	2020-03-17 08:14:50.292037956 +0100
+++ /home/bf/build/buildfarm-idiacanthus/HEAD/pgsql.build/src/bin/pg_upgra=
de/tmp_check/regress/results/misc_functions.out	2020-03-28 13:55:12.490024=
822 +0100
@@ -169,11 +169,7 @@
 =

 select (w).size =3D :segsize as ok
 from (select pg_ls_waldir() w) ss where length((w).name) =3D 24 limit 1;
- ok =

-----
- t
-(1 row)
-
+ERROR:  could not stat file "pg_wal/000000010000000000000078": No such fi=
le or directory
 select count(*) >=3D 0 as ok from pg_ls_archive_statusdir();
  ok =

 ----

It's pretty obvious what happened here: concurrent activity renamed or
removed the WAL segment between when we saw it in the directory and
when we tried to stat() it.

This seems like it would be just as much of a hazard for field usage
as it is for regression testing, so I propose that we fix these
directory-scanning functions to silently ignore ENOENT failures from
stat().  Are there any for which we should not do that?

			regards, tom lane