Re: Reducing connection overhead in pg_upgrade compat check phase - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: Reducing connection overhead in pg_upgrade compat check phase
Date
Msg-id 89A64E5D-D3DC-4806-B038-CD493F5F5510@yesql.se
Whole thread Raw
In response to Re: Reducing connection overhead in pg_upgrade compat check phase  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Reducing connection overhead in pg_upgrade compat check phase  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
> On 23 Feb 2023, at 15:12, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> On 22 Feb 2023, at 20:20, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
>> One thing I noticed is that the
>> "failed check" log is only printed once, even if multiple data type checks
>> failed.  I believe this is because this message uses PG_STATUS.  If I
>> change it to PG_REPORT, all of the "failed check" messages appear.  TBH I'm
>> not sure we need this message at all since a more detailed explanation will
>> be printed afterwards.  If we do keep it around, I think it should be
>> indented so that it looks more like this:
>>
>>     Checking for data type usage                                checking all databases
       
>>         failed check: incompatible aclitem data type in user tables
>>         failed check: reg* data types in user tables
>
> Thats a good point, that's better.  I think it makes sense to keep it around.
>
>>> One change this brings is that check.c contains version specific checks in the
>>> struct.  Previously these were mostly contained in version.c (some, like the
>>> 9.4 jsonb check was in check.c) which maintained some level of separation.
>>> Splitting the array init is of course one option but it also seems a tad messy.
>>> Not sure what's best, but for now I've documented it in the array comment at
>>> least.
>>
>> Hm.  We could move check_for_aclitem_data_type_usage() and
>> check_for_jsonb_9_4_usage() to version.c since those are only used for
>> determining whether the check applies now.  Otherwise, IMO things are in
>> roughly the right place.  I don't think it's necessary to split the array.
>
> Will do, thanks.

The attached v3 is a rebase to handle conflicts and with the above comments
adressed.

--
Daniel Gustafsson


Attachment

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
Next
From: Andrew Dunstan
Date:
Subject: Re: Add support for DEFAULT specification in COPY FROM