Re: pg_upgrade fails with in-place tablespace

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Rui Zhao <xiyuan(dot)zr(at)alibaba-inc(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade fails with in-place tablespace
Date: 2023-08-19 04:45:40
Message-ID: ZOBI9A+jXug67tt+@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 18, 2023 at 10:47:04PM +0800, Rui Zhao wrote:
> I have implemented the changes you suggested in our previous
> discussion. I have added the necessary code to ensure that
> pg_upgrade fails gracefully with in-place tablespaces and reports a
> hint to let the check pass.

+ /*
+ * No need to check in-place tablespaces when allow_in_place_tablespaces is
+ * on because they are part of the data folder.
+ */
+ if (allow_in_place_tablespaces)
+ snprintf(query, sizeof(query),
+ "%s AND pg_catalog.pg_tablespace_location(oid) != 'pg_tblspc/' || oid", query);

I am not sure to follow the meaning of this logic. There could be
in-place tablespaces that got created with the GUC enabled during a
session, while the GUC has disabled the GUC. Shouldn't this stuff be
more restrictive and not require a lookup at the GUC, only looking at
the paths returned by pg_tablespace_location()?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-08-19 04:47:48 Re: Ignore 2PC transaction GIDs in query jumbling
Previous Message John Naylor 2023-08-19 04:41:56 Re: [PATCH] Add function to_oct