Horton

Re: pg_rewind fails on Windows where tablespaces are used

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Michael Paquier <michael@paquier.xyz>, Alexandra Wang <alexandra.wang.oss@gmail.com>
Cc: Chris Travers <chris.travers@stormatics.tech>, Farooq Rashed <farooq.rashed@desc.gov.ae>, pgsql-bugs@lists.postgresql.org
Date: 2024-10-28T19:00:12Z
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 2024-10-23 We 7:03 PM, Michael Paquier wrote:
> 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.


Well, it seems like it's clearly a bug. I'm never happy leaving bugs 
unfixed. As for 12, what's the point of putting out one last release if 
it's not to fix bugs?


EDB's customer will probably be happy if we just fix 15, but I would 
rather take a broader view and fix it for other possible users too.


I'm traveling for a few days but it was my intention to work on these 
when I am back.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com