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

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18297: Error when adding a column to a parent table with complex inheritance
Date: 2024-01-23 03:19:57
Message-ID: CAHewXNkf7Th5-5F_fgWcAb88jOJx=K03J=P17cLjfEMM2BQahA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexander Lakhin <exclusion(at)gmail(dot)com> 于2024年1月23日周二 01:00写道:

> Hi,
>
> 22.01.2024 13:36, Tender Wang wrote:
>
>
> Yes, I've encountered a similar issue, this time with ALTER (TEXT SEARCH
>> CONFIGURATION):
>> CREATE TEXT SEARCH CONFIGURATION ispell_tst (COPY=english);
>> CREATE TEXT SEARCH DICTIONARY ispell (Template=ispell,
>> DictFile=ispell_sample, AffFile=ispell_sample);
>> ALTER TEXT SEARCH CONFIGURATION ispell_tst ALTER MAPPING FOR word, word
>> WITH ispell;
>> ERROR: tuple already updated by self
>>
>
> Yes, this is another issue that DDL operation on an same object twice.
> Maybe we can report error on Parse phase.
> But as you say, all the other DDL commands run OK, so maybe it's better to
> process this case in execution phase.
> I will send a patch later.
>
>
> Thank you for working on this!
>
> As these two cases look like exceptions to the common behavior, I wonder
> whether we need some extra functions to deal with duplicates.
> (I haven't look yet how such duplicates processed for other object types.)
>

For example, drop extension pageinspect ,pageinspect;
The duplicates will be done in object_address_present_add_flags(), some
codes as below:
....
if (object->classId == thisobj->classId &&
object->objectId == thisobj->objectId)
{
if (object->objectSubId == thisobj->objectSubId)
{
ObjectAddressExtra *thisextra = addrs->extras + i;

thisextra->flags |= flags;
result = true;
}
....
The object will not be added to targetObjects if above func returned true.

Your reported two issues have different code path, and duplicates do not
processed.

I am considering whether there is a unified way of handling this, otherwise
each one will have to be dealt with separately.

>
> And I'm just curious that how do you find these issues? Use some tools?
>
>
>
> I discovered these two issues with my kind of fuzzer, just watching out
> for the interesting errors.
>
> Best regards,
> Alexander
>

--
Tender Wang
OpenPie: https://en.openpie.com/

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message feichanghong 2024-01-23 03:39:00 Re: MarkBufferDirty Assert held LW_EXCLUSIVE lock fail when ginFinishSplit
Previous Message Michael Paquier 2024-01-23 01:15:27 Re: MarkBufferDirty Assert held LW_EXCLUSIVE lock fail when ginFinishSplit