On Mon, Jul 31, 2023 at 5:36 PM Rui Zhao <xiyuan...@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_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
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
