Re: pg_upgrade fails with in-place tablespace
| От | Michael Paquier | 
|---|---|
| Тема | Re: pg_upgrade fails with in-place tablespace | 
| Дата | |
| Msg-id | ZOBI9A+jXug67tt+@paquier.xyz обсуждение исходный текст | 
| Ответ на | Re: pg_upgrade fails with in-place tablespace ("Rui Zhao" <xiyuan.zr@alibaba-inc.com>) | 
| Ответы | Re: pg_upgrade fails with in-place tablespace | 
| Список | 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
Вложения
В списке pgsql-hackers по дате отправления: