Re: BUG #18310: Some SQL commands fail to process duplicate objects with error: tuple already updated by self

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18310: Some SQL commands fail to process duplicate objects with error: tuple already updated by self
Date: 2024-01-30 08:02:06
Message-ID: CAHewXNmh6PoS4+JvdprLJOe+gFWnaLAmagCs43Y2du=XC65Qcw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Michael Paquier <michael(at)paquier(dot)xyz> 于2024年1月30日周二 15:42写道:

> On Tue, Jan 30, 2024 at 03:29:46PM +0800, Tender Wang wrote:
> > Michael Paquier <michael(at)paquier(dot)xyz> 于2024年1月30日周二 14:28写道:
> > I misunderstund the behavior in getTokenTypes() and in
> > DropConfigurationMapping(). I only realized it can fix the reported
> issue.
>
> Well, I don't think you should blame yourself, so no worries we are
> all here to learn :)
>
> tsdicts.sql has little to no coverage of the various grammar flavors
> we are discussing here, so we should try to close the hole with all
> the expectations I've just guessed while analyzing the code and the
> patch. So it is a
> problem of fixing the root issue as much as expanding the regression
> tests with token names and IF EXISTS.
>
> >> I think that we should tweak getTokenTypes() so as we return *two*
> >> Lists, one for the IDs and a second with the token names, then use
> >> forboth() in DropConfigurationMapping() with the two lists and a
> >> simple foreach in MakeConfigurationMapping() when overriding the
> >> mappings, while getTokenTypes() checks if a number is in the first
> >> list before adding the name of a token in the second list. Or we
> >> could use a simple list with pointers to a local structure, but the
> >> second list is only needed by DropConfigurationMapping(). That would
> >> enforce a correct order of the token names and numbers, at least.
> >> I would be tempted to just use one List with a structure (number,
> >> token_name). It makes the checks for duplicates O(N^2) but we will
> >> never have hundreds of mapping entries in these DDL queries.
> >>
> >
> > Hmm, I agree with you.
>
> Perhaps you'd like to give it a second try? Based on my suggestion,
> you just need to englobe the tokens retrieved into a single structure
> like that:
> typedef struct
> {
> int num;
> char *name;
> } TSTokenTypes;
>
> Then handle a List of these (could be as well an array with its length
> returned as an output argument of getTokenTypes(), to keep a
> non-duplicated list of tokens with a strict mapping between token name
> and token number.
>

Thanks a lot. I want to give it a second try. I will send a patch based on
your suggestion.

> --
> Michael
>

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2024-01-30 08:14:55 Re: BUG #18310: Some SQL commands fail to process duplicate objects with error: tuple already updated by self
Previous Message Michael Paquier 2024-01-30 07:42:10 Re: BUG #18310: Some SQL commands fail to process duplicate objects with error: tuple already updated by self