Re: mcvstats serialization code is still shy of a load

On Tue, Jul 02, 2019 at 10:38:29AM +0200, Tomas Vondra wrote:
>On Sun, Jun 30, 2019 at 08:30:33PM -0400, Tom Lane wrote:
>>Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>>>Attached is a slightly improved version of the serialization patch.
>>
>>I reviewed this patch, and tested it on hppa and ppc.  I found one
>>serious bug: in the deserialization varlena case, you need
>>
>>-                    dataptr += MAXALIGN(len);
>>+                    dataptr += MAXALIGN(len + VARHDRSZ);
>>
>>(approx. line 1100 in mcv.c).  Without this, the output data is corrupt,
>>plus the Assert a few lines further down about dataptr having been
>>advanced by the correct amount fires.  (On one machine I tested on,
>>that happened during the core regression tests.  The other machine
>>got through regression, but trying to do "select * from pg_stats_ext;"
>>afterwards exhibited the crash.  I didn't investigate closely, but
>>I suspect the difference has to do with different MAXALIGN values,
>>4 and 8 respectively.)
>>
>>The attached patch (a delta atop your v2) corrects that plus some
>>cosmetic issues.
>>
>
>Thanks.
>
>>If we're going to push this, it would be considerably less complicated
>>to do so before v12 gets branched --- not long after that, there will be
>>catversion differences to cope with.  I'm planning to make the branch
>>tomorrow (Monday), probably ~1500 UTC.  Just sayin'.
>>
>
>Unfortunately, I was travelling on Sunday and was quite busy on Monday, so
>I've been unable to push this before the branching :-(
>
>I'll push by the end of this week, once I get home.
>

I've pushed the fix (along with the pg_mcv_list_item fix) into master,
hopefully the buildfarm won't be upset about it.

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".

I suppose this is not the first time this happened - how did we deal
with it in the past? I guess we could use some "past" non-conflicting
catversion number in the REL_12_STABLE branch (say, 201907030x) but
maybe that'd be wrong?

regards

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