From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | CG <cgg007(at)yahoo(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Off-label use for pg_repack |
Date: | 2023-11-28 17:05:37 |
Message-ID: | 06c52536-a3f0-488a-b511-25a532d7c504@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/28/23 08:46, CG wrote:
> Hi fellow list members. I hit a brick wall with my last question. I'd
> like to try this again.
>
> I need to remove OIDs from tables without locking the tables for long
> periods of time. I have developed a strategy that seems to work, but I
> would like the experts to weigh in since I'm planning on doing things to
> the system tables that are generally frowned upon.
>
> Prior to running pg_repack I perform these modifications:
>
> mydata=# update pg_class set relhasoids = false where oid =
> 'a_very_large_table_with_oids'::regclass::oid;
> UPDATE 1
> mydata=# delete from pg_attribute where attrelid =
> 'a_very_large_table_with_oids'::regclass::oid and attname = 'oid';
> DELETE 1
Not sure about the below, but in the above: ::regclass::oid is
redundant, ::regclass will suffice. Also for pg_class you can do where
relname = 'a_very_large_table_with_oids';
> mydata=# \d+ a_very_large_table_with_oids;
> Table "public.a_very_large_table_with_oids"
> Column | Type | Modifiers | Storage | Stats target | Description
> --------+------+-----------+----------+--------------+-------------
> k | text | not null | extended | |
> v | text | | extended | |
> Indexes:
> "a_very_large_table_with_oids_pkey" PRIMARY KEY, btree (k)
>
> mydata=# select oid,* from a_very_large_table_with_oids;
> ERROR: column "oid" does not exist
>
> So far so good. I can insert update and delete rows, but the table
> structure on disk is unchanged.
>
> So after those modifications I repack the table with vanilla pg_repack.
> That copies the data to a fresh new table, sans oids.
>
> Before I start performing these operations on-line on the production
> data I wanted some expert eyes on this process since this is mission
> critical stuff. On the very large tables we will be in this limbo state
> for an extended period of time where pg_class and pg_attribute will have
> those forced modifications while pg_repack works its magic. Is there
> anything to be concerned about if insert/update/delete seems to be
> working? My insert/update/deletes on the tables while pg_repack is
> running seem to work fine. I also tried this on tables that have toast
> tables attached and upon first glance, everything seems to be in order.
>
> What have I missed?
>
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2023-11-28 17:53:17 | Re: Get back the number of columns of a result-set prior to JSON aggregation |
Previous Message | hector vass | 2023-11-28 17:05:10 | Re: Get back the number of columns of a result-set prior to JSON aggregation |