From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
---|---|
To: | "Mohamed Wael Khobalatte" <mkhobalatte(at)grubhub(dot)com> |
Cc: | "Michael Lewis" <mlewis(at)entrata(dot)com>,"pgsql-general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Switching Primary Keys to BigInt |
Date: | 2020-07-22 13:27:08 |
Message-ID: | 029f54d9-99ec-49d2-b8eb-567bf6b4f3ce@manitou-mail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Mohamed Wael Khobalatte wrote:
> > alter table change_seq alter COLUMN id set data
> > type bigint;
> This is significant downtime, since it locks exclusively, no? We want to
> avoid that.
Well, in the steps you mentioned upthread, the transaction starts by
doing LOCK TABLE some_table, so it will hold an exclusive lock on it
for the rest of the transaction.
If you can test how the ALTER TABLE... SET TYPE ... compares
to your procedure in terms of downtime, that would be interesting.
To me, it's not clear why the procedure in multiple steps would
be better overall than a single ALTER TABLE.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: https://www.manitou-mail.org
Twitter: @DanielVerite
From | Date | Subject | |
---|---|---|---|
Next Message | Mohamed Wael Khobalatte | 2020-07-22 14:39:15 | Re: Switching Primary Keys to BigInt |
Previous Message | Thomas Kellerer | 2020-07-22 11:10:44 | Re: Logical replication from 11.x to 12.x and "unique key violations" |