Request for Insights on ID Column Migration Approach

From: Aditya Singh <aditya(dot)singh(at)lji(dot)io>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Request for Insights on ID Column Migration Approach
Date: 2024-09-30 17:05:00
Message-ID: CAE_cSysUnG=1ApLSi_BMv6TOvOVXPTbVdwdFUCrkfTruN0Co2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I am just contacting you to talk about a current issue with our database.
We have run out of a positive sequence in one of our tables and are now
operating with negative sequences. To address this, we plan to migrate from
the int4 ID column to an int8 ID column.

The plan involves renaming the int8 column to the id column and setting it
as the primary key. However, this process will require downtime, which may
be substantial in a production environment. Fortunately, we have noted that
other tables do not use the id column as a foreign key, which may help
mitigate some concerns.
Our Approach:

1.

*Copy Data: *Copy all the data to the new *id_copy* column.
2.

*C**reate a Unique Index*: We will then create a unique index on the new
ID column before renaming it ,and alter it to non-nullable. This step will
necessitate scanning the entire table to verify uniqueness and
non-nullability.
3.

*A**dd Primary Key*: After ensuring the uniqueness, we will add the ID
column as the primary key. By doing this, we hope to bypass the additional
scanning for uniqueness and nullability, as the column will already be set
as not nullable and will have the uniqueness constraint from the unique
index.

We want to confirm if this approach will work as expected. If we should be
aware of any potential pitfalls or considerations, could you please provide
insights or point us toward relevant documentation?

Thank you so much for your help, and I look forward to your guidance.

Best regards,

Aditya Narayan Singh
Loyalty Juggernaut Inc.

--

*Confidentiality Warning:*
This message and any attachments are intended
only for the use of the intended recipient(s), are confidential, and may be
privileged. If you are not the intended recipient, you are hereby notified
that any disclosure, copying, distribution, or other use of this message
and any attachments is strictly prohibited. If received in error, please
notify the sender immediately and permanently delete it.

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2024-09-30 17:09:31 Re: May be BUG. Periodic burst growth of the checkpoint_req counter on replica.
Previous Message Antonin Houska 2024-09-30 16:54:28 Re: [PoC] Federated Authn/z with OAUTHBEARER