On 2023-01-12 Th 00:12, Justin Pryzby wrote:
> On Wed, Jan 11, 2023 at 10:45:33PM -0500, Tom Lane wrote:
>> Amit Langote <amitlangote09@gmail.com> writes:
>>> On Thu, Jan 12, 2023 at 10:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> I've pushed this with some cleanup --- aside from fixing
>>>> outfuncs/readfuncs, I did some more work on the comments, which
>>>> I think you were too sloppy about.
>>> Thanks a lot for the fixes.
>> It looks like we're not out of the woods on this: the buildfarm
>> members that run cross-version-upgrade tests are all unhappy.
>> Most of them are not reporting any useful details, but I suspect
>> that they are barfing because dumps from the old server include
>> table-qualified variable names in some CREATE VIEW commands while
>> dumps from HEAD omit the qualifications. I don't see any
>> mechanism in TestUpgradeXversion.pm that could deal with that
>> conveniently, and in any case we'd have to roll out a client
>> script update to the affected animals. I fear we may have to
>> revert this pending development of better TestUpgradeXversion.pm
>> support.
> There's a diffs available for several of them:
>
> - SELECT citext_table.id,
> - citext_table.name
> + SELECT id,
> + name
>
> It looks like TestUpgradeXversion.pm is using the diff command I sent to
> get tigher bounds on allowable changes.
>
> 20210415153722.GL6091@telsasoft.com
>
> It's ugly and a terrible hack, and I don't know whether anyone would say
> it's good enough, but one could can probably avoid the diff like:
>
> sed -r '/CREATE/,/^$/{ s/\w+\.//g }'
>
> You'd still have to wait for it to be deployed, though.
That looks quite awful. I don't think you could persuade me to deploy it
(We don't use sed anyway). It might be marginally better if the pattern
were /CREATE.*VIEW/ and we ignored that first line, but it still seems
awful to me.
Another approach might be simply to increase the latitude allowed for
old versions <= 15 with new versions >= 16. Currently we allow 90 for
cases where the versions differ, but we could increase it to, say, 200
in such cases (we'd need to experiment a bit to find the right limit).
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com