Sorry for the late reply. I had apparently had it buried.
On Wed, Jul 10, 2024 at 6:12 AM Michael Paquier <michael@paquier.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.
