Re: bug when apply fast default mechanism for adding new column over domain with default value
| От | Tender Wang |
|---|---|
| Тема | Re: bug when apply fast default mechanism for adding new column over domain with default value |
| Дата | |
| Msg-id | CAHewXNmGmNkkCB73uvk9nP0NJ08JOwAYM8tWEmvQL1f-EH3uOA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: bug when apply fast default mechanism for adding new column over domain with default value (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: bug when apply fast default mechanism for adding new column over domain with default value
|
| Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> 于2025年4月2日周三 09:05写道：
Alexander Lakhin <exclusion@gmail.com> writes:
> I've discovered that 95f650674 introduced a defect similar to bug #18297,
> but this time with DEFAULT. Namely, the following script:
> CREATE TABLE a (aa text);
> CREATE TABLE c (cc text) INHERITS (a);
> CREATE TABLE d (dd text) INHERITS (c, a);
> ALTER TABLE a ADD COLUMN i int DEFAULT 1;
> fails with:
> ERROR: XX000: tuple already updated by self
> LOCATION: simple_heap_update, heapam.c:4421
Hmm, yeah. The failing call is here:
/* Bump the existing child att's inhcount */
...
CatalogTupleUpdate(attrdesc, &tuple->t_self, tuple);
so I think you're right that that code path is now short a
CommandCounterIncrement() somewhere. I'll look tomorrow if
nobody beats me to it.
Yes, when table a process its children, which are table c and table d. Table c is first to be done.
At the same time, table d is also child of table c, so after updating own pg_attribute tuple, table c will
process its child table d. And table d update its pg_attribute catalog tuple.
After finishing table c, the logic returning to continue to process table a's children, which this time is table d.
Between table d pg_attribute tuple updated as child of table c and updating table d pg_attribute tuple again as child of table a,
there is no call CommandCounterIncrement().
So let's add CommandCounterIncrement() after calling StoreAttrMissingVal().
Thanks, Tender Wang
Вложения
В списке pgsql-hackers по дате отправления: