From: | Mohamed Wael Khobalatte <mkhobalatte(at)grubhub(dot)com> |
---|---|
To: | Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Switching Primary Keys to BigInt |
Date: | 2020-07-21 21:18:13 |
Message-ID: | CABZeWdwsaMvjU7ECLKpAr5WZVp+5LS7NAcqhzg1KHkFHQQr1xQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> > test_(aklaver)5432> alter table change_seq alter COLUMN id set data
type
> bigint;
> ALTER TABLE
> test_(aklaver)5432> \d change_seq
> Table "public.change_seq"
> Column | Type | Collation | Nullable | Default
> --------+--------+-----------+----------+-------------------
---------------------
>
> id | bigint | | not null |
> nextval('change_seq_id_seq'::regclass)
> Indexes:
> "change_seq_pkey" PRIMARY KEY, btree (id)
This is significant downtime, since it locks exclusively, no? We want to
avoid that.
> Side note- EOL for 9.6 is coming next year so just a plug for upgrading
when possible, perhaps utilizing pglogical to get to v11 or 12.
Yep, we are painfully aware. The id growth will beat us to it, so we need
to deal with that first.
From | Date | Subject | |
---|---|---|---|
Next Message | Michał Lis | 2020-07-21 21:35:22 | Problem with pg_service.conf |
Previous Message | Michael Lewis | 2020-07-21 18:43:21 | Re: Switching Primary Keys to BigInt |