Hello postgres hackers,
Recently I encountered an issue: pg_upgrade fails when dealing with in-place tablespace. As we know, pg_upgrade uses pg_dumpall to dump objects and pg_restore to restore them. The problem seems to be that pg_dumpall is dumping in-place tablespace as 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 change the 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. Because the 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 solution may be more lightweight and harmless.
Thank you for your attention to this matter.
Best regards,
Rui Zhao