Horton

Re: pg_rewind fails on Windows where tablespaces are used

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Alexandra Wang <alexandra.wang.oss@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Chris Travers <chris.travers@stormatics.tech>, Farooq Rashed <farooq.rashed@desc.gov.ae>, pgsql-bugs@lists.postgresql.org
Date: 2024-10-23T23:03:32Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix readlink() for non-PostgreSQL junction points on Windows.

  2. Fix stat() for recursive junction points on Windows.

  3. Fix pg_rewind with in-place tablespaces when source is remote

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

  5. Use in-place tablespaces in regression test.

On Wed, Oct 23, 2024 at 11:19:14AM -0500, Alexandra Wang wrote:
> I encountered this issue while working on the fix for branch 14 and
> running the tablespace regress test. This simple test is not covered
> in branch 15’s regress tests, as we started setting
> allow_in_place_tablespaces = true since commit d6d317db.

Yes, for the reasons stated in this commit because we rely on
everything to be on the same host, and tablespace paths would overlap
across the primary and its replica.

> I also had to backpatch additional commits for branches 12 to 14, as
> follows:
> 
> branch 14: e2f0f8ed, af9e6331, and the commits for branch 15
> [f357233c, c5cb8f3b, 387803d8, and 5fc88c5d53].
> branches 12 & 13: bed90759, 54fb8c7d, de8feb1f, 101c37cd, and the
> commits for branch 14.
> 
> With these additional commits for branches 12 to 14, I’m not sure if
> it’s worth backpatching, or should we backpatch only to branch 15?

12 is going to be EOL in a couple of days, so I'd rather leave it out.
If it were down to me, I'd also leave 13 and 14 as well, based on
e2f0f8ed25 to let the beast sleep there.  Perhaps others have a
different opinion. though.

> I agree with Andrew that if we decide to backpatch these changes, we
> should add tests for the pg_rewind issue. Would the pg_rewind TAP
> tests be the place for them?

Looking at your patch set, it strikes me as not really necessary to
involve multiple nodes to check the lstat() emulation, the failure
originating not really from pg_rewind, but from the contents of
src/port/.  Your DROP TABLESPACE case is telling us that, at least, so
we could use a single node with tablespace manipulations to get
basically to the same coverage?  Perhaps pg_checksums is one piece to
look at, as it relies on a single node.  And that would be less costly.
--
Michael