Re: ALTER TABLE ADD COLUMN fast default

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ALTER TABLE ADD COLUMN fast default
Date: 2021-04-06 15:01:55
Message-ID: 1011391.1617721315@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> This gitlab ticket refers to the same incident:
> https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6047
> (which actually contains a new relevant fact that hadn't been mentioned
> in the IRC discussion, which is that the problem affected multiple
> tables, not just one.)

Hmm. If you assume that the problem is either a corrupted index on
pg_attrdef, or some block(s) of pg_attrdef got zeroed out, then it
would be entirely unsurprising for multiple tables to be affected.

I've pushed the v2 patch to HEAD. Not sure if we want to consider
back-patching.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-04-06 15:11:02 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Previous Message Himanshu Upadhyaya 2021-04-06 14:47:57 [PATCH] PREPARE TRANSACTION unexpected behavior with TEMP TABLE