Horton

Re: pg_upgrade test failure

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-09-20T01:08:41Z
Lists: pgsql-hackers 
On Mon, Sep 19, 2022 at 02:32:17PM -0700, Andres Freund wrote:
> I don't know if actually related to the commit below, but there've been a
> lot of runs of the pg_upgrade tests in the meson branch, and this is the first
> failure of this kind. Unfortunately the error seems to be transient -
> rerunning the tests succeeded.

This smells to me like a race condition in pg_upgrade (or even pg_ctl
for SERVER_LOG_FILE) where the code still has handles on some of the
files in the log/ subdirectory, causing its removal to not be able to
finish happen.  If this proves to be rather easy to reproduce, giving
a list of the files still present in this path would give a hint easy
to follow.  Does this reproduce with a good frequency?
--
Michael

Commits

  1. ci: freebsd: stop postgres instance on failure, to prevent log upload failures

  2. Try to fix pg_upgrade test on Windows, again.

  3. Refactor rmtree() to use get_dirent_type().

  4. Fix unlink() for STATUS_DELETE_PENDING on Windows.

  5. Move any remaining files generated by pg_upgrade into an internal subdir

  6. Make unlink() work for junction points on Windows.

  7. pg_upgrade: Move all the files generated internally to a subdirectory

  8. In pg_upgrade, try a few times to open a log file.