Re: pg_rewind fails with in-place tablespace
От | Michael Paquier |
---|---|
Тема | Re: pg_rewind fails with in-place tablespace |
Дата | |
Msg-id | ZMN0ULLVyKxTaCKr@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pg_rewind fails with in-place tablespace (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_rewind fails with in-place tablespace
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: