From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Chris Travers <chris(dot)travers(at)stormatics(dot)tech>, Farooq Rashed <farooq(dot)rashed(at)desc(dot)gov(dot)ae>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_rewind fails on Windows where tablespaces are used |
Date: | 2024-07-09 23:12:29 |
Message-ID: | Zo3D3Y24Kd1eTV8n@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-07-10 01:15:37 | Re: Potential data loss due to race condition during logical replication slot creation |
Previous Message | Andrew Dunstan | 2024-07-09 16:01:17 | Re: pg_rewind fails on Windows where tablespaces are used |