| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, 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 03:52:44 |
| Message-ID: | 87lf9wozcx.fsf@news-spur.riddles.org.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>>>> "Andrew" == Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
Andrew> I'd be curious to know how this state came about.
Me too, but available information is fairly sparse: PG 12.5, in a
container, backing a (personal) instance of Gitlab; the only database
admin operations should have been those done by Gitlab itself, but I
have not audited that codebase. No information on any history of
crashes. The missing pg_attrdef row appeared to be missing or not
visible in the heap, not just missing from indexes; it did not show up
in queries whether seqscan or indexscan was used. Available time did not
permit trying to use pageinspect on pg_attrdef.
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.)
--
Andrew (irc:RhodiumToad)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2021-04-06 03:58:08 | Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays |
| Previous Message | Masahiko Sawada | 2021-04-06 03:23:56 | Re: Table refer leak in logical replication |