Re: Adding a non-null column without noticeable downtime

From: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
To: Zev Benjamin <zev-pgsql(at)strangersgate(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Adding a non-null column without noticeable downtime
Date: 2014-02-26 06:44:25
Message-ID: 530D8D49.30206@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 02/25/2014 04:41 AM, Zev Benjamin wrote:
> I'm conceptually trying to do
> ALTER TABLE "foo" ADD COLUMN "bar" boolean NOT NULL DEFAULT False;
>
> without taking any noticeable downtime. I know I can divide the query
> up like so:
>
> ALTER TABLE "foo" ADD COLUMN "bar" boolean;
> UPDATE foo SET bar = False; -- Done in batches
> ALTER TABLE "foo" ALTER COLUMN "bar" SET DEFAULT False;
> ALTER TABLE "foo" ALTER COLUMN "bar" SET NOT NULL;

You need to set the default before doing the update. Also, make sure
the update is in its own transaction.

> The first 3 queries shouldn't impact other concurrent queries on the
> system. My question is about the sequential scan that occurs when
> setting the column NOT NULL. Will that sequential scan block other
> inserts or selects on the table?

Yes, because ALTER TABLE will have taken an AccessExclusiveLock.

> If so, can it be sped up by using an index (which would be created
> concurrently)?

Unfortunately not.

--
Vik

In response to

Browse pgsql-general by date

  From Date Subject
Next Message john gale 2014-02-26 07:45:18 Re: cannot delete corrupted rows after DB corruption: tuple concurrently updated
Previous Message Sergey Konoplev 2014-02-26 01:15:13 Re: Adding a non-null column without noticeable downtime