Re: pg_rewind fails on Windows where tablespaces are used

Sorry for the late reply. I had apparently had it buried.

On Wed, Jul 10, 2024 at 6:12 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Tue, Jul 09, 2024 at 12:01:17PM -0400, Andrew Dunstan wrote:
> > The solution I came up with was to backpatch commits c5cb8f3b, 387803d8
> and
> > 5fc88c5d53.
>
> The lstat() wrapper for Windows, noted.
>
> > I don't think we need to do anything relating to in-place tablespaces.
> These
> > are documented as a developer only option and not for production.
>
> Okay, cool.
>
>
Yeah in place tablespaces are not used. They did have to be briefly
enbaled due to another issue probably with the same wrapper but they were
never used. They were disabled again shortly after.

> > The only question in my mind is whether those patches should be
> > backpatched.
> >
> > It's a couple of hundred lines, and I think it's safe, but I'd welcome
> other
> > opinions. If we are going to backpatch them we should also look at
> adding to
> > adding tests for use of tablespaces with pg_rewind on the back branches.
> > Ideally we'd get this done in time for the next maintenance release.
>
> Seeing that the commits all go down to v16, meaning that these have
> brewed across 3 minor releases already, I'd like to assume that we
> would have already heard about problems related to them. So that
> seems like a rather safe thing to do at this stage.
>

Just as some added context, I have noticed that manually moving a
tablespace and creating the junction with mklink /d sometimes causes
PostgreSQL to decide this must be an in place tablespace even though dir
clearly shows it as a junction. I don't have the resources to determine if
this is limited to some builds of Windows or patch levels but the problem
goes away after a pg_basebackup rebuild so I don;t think it is something
that is so urgent, So this is more of a note that there seem to be some
issues in this area on Windows at least in 15. I don't know if that
affects discussion but it is worth noting.

Michael
>