Re: mcvstats serialization code is still shy of a load

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: mcvstats serialization code is still shy of a load
Date: 2019-07-05 16:04:56
Message-ID: 20190705160456.p7qnutz2stlzxu2f@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 05, 2019 at 10:36:59AM +0200, Tomas Vondra wrote:
>On Fri, Jul 5, 2019, 03:28 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
>> > I was about to push into REL_12_STABLE, when I realized that maybe we
>> > need to do something about the catversion first. REL_12_STABLE is still
>> > on 201906161, while master got to 201907041 thanks to commit
>> > 7b925e12703. Simply cherry-picking the commits would get us to
>> > 201907052 in both branches, but that'd be wrong as the catalogs do
>> > differ. I suppose this is what you meant by "catversion differences to
>> > cope with".
>>
>> Yeah, exactly.
>>
>> My recommendation is to use 201907051 on v12 and 201907052
>> on master (or whatever is $today for you). They need to be
>> different now that the branches' catalog histories have diverged,
>> and it seems to me that the back branch should be "older".
>>
>> regards, tom lane
>>
>
>Unfortunately, master is already using both 201907051 and 201907052 (two of
>the patches I pushed touched the catalog), so we can't quite do exactly
>that. We need to use 201907042 and 201907043 or something preceding 201907041
>(which is the extra catversion on master).
>
>At this point there's no perfect sequence, thanks to the extra commit on
>master, so REL_12_STABLE can't be exactly "older" :-(
>
>Barring objections, I'll go ahead with 201907042+201907043 later today,
>before someone pushes another catversion-bumping patch.
>

I've pushed the REL_12_STABLE backpatches too, now. I've ended up using
201907031 and 201907032 - those values precede the first catversion bump
in master (201907041), so the back branch looks "older". And there's a
bit of slack for additional bumps (if the unlikely case we need them).

We might have "fixed" this by backpatching the commit with the extra
catversion bump (7b925e12) but the commit seems a bit too large for
that. It's fairly isolated though. But it seems like a bad practice.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-07-05 16:14:31 Re: Fix runtime errors from -fsanitize=undefined
Previous Message Euler Taveira 2019-07-05 15:19:24 Re: Inconsistency between attname of index and attname of relation