BUG #19051: Is it possible to move a TOAST table to a different tablespace than its parent table?
От | PG Bug reporting form |
---|---|
Тема | BUG #19051: Is it possible to move a TOAST table to a different tablespace than its parent table? |
Дата | |
Msg-id | 19051-90b4476ef19f9b73@postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #19051: Is it possible to move a TOAST table to a different tablespace than its parent table?
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 19051 Logged by: Mustafa HARARCI Email address: mhararci@gmail.com PostgreSQL version: 16.10 Operating system: Ubuntu 16.10-1.pgdg22.04+1 Description: Hello everyone, I'm currently using PostgreSQL 16.10 and I've run into a challenge regarding moving TOAST data for a table. My goal is to have the TOAST data for a column stored in a different tablespace from the parent table. Specifically, I have a users table with a profile_data column of type JSONB, which can contain large objects. I want the users table itself to reside in the ts_medium_data tablespace, while its associated TOAST data is stored in a separate ts_medium_toast tablespace. I've attempted the following steps: I created the users table in the ts_medium_data tablespace. I identified the associated TOAST table using the pg_class catalog (SELECT reltoastrelid::regclass FROM pg_class WHERE relname = 'users';), which returned an object like pg_toast.pg_toast_16646. As a superuser (postgres), I tried to move the TOAST table to the new tablespace using ALTER TABLE pg_toast.pg_toast_16646 SET TABLESPACE ts_medium_toast;. This command, however, resulted in the following error: ERROR: permission denied: "pg_toast_16646" is a system catalog. This error suggests that direct modification of the TOAST table is not allowed, even with superuser privileges. My question is, is it fundamentally possible in PostgreSQL to store a table's main data and its TOAST data in different tablespaces? Is this behavior a design constraint? If so, is there any workaround for this, or is this simply not a supported feature? Any insight into this behavior or guidance on a potential solution would be greatly appreciated. Thank you.
В списке pgsql-bugs по дате отправления: