Re: pg_upgrade fails with in-place tablespace

On Mon, Jul 31, 2023 at 5:36 PM Rui Zhao <xiyuan.zr@alibaba-inc.com> wrote:
>
> Hello postgres hackers,
> Recently I encountered an issue: pg_upgrade fails when dealing with in-place tablespace. As we know, pg_upgrade uses
pg_dumpallto dump objects and pg_restore to restore them. The problem seems to be that pg_dumpall is dumping in-place
tablespaceas relative path, which can't be restored. 
>
> Here is the error message of pg_upgrade:
>
psql:/home/postgres/postgresql/src/bin/pg_upgrade/tmp_check/t_002_pg_upgrade_new_node_data/pgdata/pg_upgrade_output.d/20230729T210058.329/dump/pg_upgrade_dump_globals.sql:36:
ERROR: tablespace location must be an absolute path 
>
> To help reproduce the failure, I have attached a tap test. The test also fails with tablespace regression, and it
changethe default value of allow_in_place_tablespaces to true only for debug, so it may not be fit for production.
However,it is enough to reproduce this failure. 
> I have also identified a solution for this problem, which I have included in the patch. The solution has two
modifications:
>   1) Make the function pg_tablespace_location returns path "" with in-place tablespace, rather than relative path.
Becausethe path of the in-place tablespace is always 'pg_tblspc/<oid>'. 
>   2) Only check the tablespace with an absolute path in pg_upgrade.
>
>   There are also other solutions, such as supporting the creation of relative-path tablespace in function
CreateTableSpace.But do we really need relative-path tablespace? I think in-place tablespace is enough by now. My
solutionmay be more lightweight and harmless. 
>
> Thank you for your attention to this matter.
>
> Best regards,
> Rui Zhao

Seems like allow_in_place_tablespaces is a developer only guc, and it
is not for end user usage.
check this commit 7170f2159fb21b62c263acd458d781e2f3c3f8bb


--
Regards
Junwang Zhao