Re: BUG #18297: Error when adding a column to a parent table with complex inheritance

Alexander Lakhin <exclusion@gmail.com> 于2024年1月18日周四 17:00写道：

> Hello Tender Wang and Richard,
>
> 17.01.2024 18:03, Tender Wang wrote:
>
> Thanks for reviewing the patch.
> The attached v2 patch includes all review advices.
>
> --
> Tender Wang
> OpenPie:  https://en.openpie.com/
>
> Richard Guo <guofenglinux@gmail.com> 于2024年1月17日周三 19:54写道：
>
>>
>> Indeed.  We may update the same child column multiple times, but there
>> is no CommandCounterIncrement between.  Nice catch and +1 to the fix.
>>
>> To nitpick, how about go with the comment as
>>
>>     /* Make sure the child column change is visible */
>>
>> which seems clearer.
>>
>> Also I think it'd be better to include a blank line before and after the
>> new CommandCounterIncrement statement.
>>
>> Also I suggest to drop the new added tables after we've run ALTER TABLE
>> in the test case.
>>
>> Thanks
>> Richard
>>
>
> Thank you for working on this!
>
> (Maybe it's possible to slightly modify an existing hierarchy with tables
> a, b, c in inherit.sql for the purpose of the check added.)
>
> I've found another situation where the same error is produced:
> CREATE ROLE u;
> DROP ROLE u, u;
> ERROR:  tuple already updated by self
>

Indeed, but this issue cann't simply calling CommandCounterIncrement() to
fix.
It will report "could not find tuple for role" if we simply calling
CommandCounterIncrement() when drop seond 'u'.

I think we can sort the role_addresses list and skip the same role id. I
don't intend to fix above two issues in one patch.
So I add a new 0001 attached patch.


Perhaps, you would like to fix it in passing too. I've rechecked all the
> other object types, that can be DROPped with a list (namely, AGGREGATE,
> DOMAIN, EXTENSION, FOREIGN DATA WRAPPER, FOREIGN TABLE, FUNCTION, INDEX,
> MATERIALIZED VIEW, OPERATOR, PROCEDURE, ROUTINE, SEQUENCE, SERVER,
> STATISTICS, TABLE, TYPE, VIEW), and found that all of these handle
> such duplicate entries with no error.
>

I'm not sure if there are other problems like this.


> Best regards,
> Alexander
>