Re: pg_rewind fails with in-place tablespace - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_rewind fails with in-place tablespace
Date
Msg-id ZMN0ULLVyKxTaCKr@paquier.xyz
Whole thread Raw
In response to Re: pg_rewind fails with in-place tablespace  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_rewind fails with in-place tablespace
List pgsql-hackers
On Tue, Jul 25, 2023 at 04:36:42PM +0900, Michael Paquier wrote:
> On Wed, Jul 19, 2023 at 09:31:35PM +0800, 赵锐(惜元) wrote:
>>  To help reproduce the failure, I have attached a tap test. And I am
>>  pleased to say that I have also identified a solution for this
>>  problem, which I have included in the patch.
>>  Thank you for your attention to this matter.
>
> Issue reproduced here, and agreed that we'd better do something about
> that.  I am not sure if your patch is right for the job though, but
> I'll try to study that a bit more.

It took me some time to remember that for the case of a local source
we'd finish by using recurse_dir() and consider the in-place
tablespace as a regular directory, so a fix located in
libpq_traverse_files() sounds good to me.

+           if (strncmp(link_target, "pg_tblspc/", strlen("pg_tblspc/")) == 0)
+               type = FILE_TYPE_DIRECTORY;
+           else
+               type = FILE_TYPE_SYMLINK;

However this is not consistent with the other places where we detect
if an in-place tablespace is used, like pg_basebackup.c, where we rely
on the fact that the tablespace path is a relative path, using
is_absolute_path() to make the difference between a normal and
in-place tablespace.  I would choose consistency and do the same here,
checking if we have an absolute or relative path, depending on the
result of pg_tablespace_location().

Testing only for the creation of the tablespace is fine for the sake
of the report, but I would slightly more here and create a table on
this tablespace with some data, and a check_query() once pg_rewind is
done.

I am finishing with the attached.  Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: add timing information to pg_upgrade
Next
From: Michael Paquier
Date:
Subject: Re: Support worker_spi to execute the function dynamically.