Thread: [HACKERS] Draft release notes up for review

[HACKERS] Draft release notes up for review

From
Tom Lane
Date:
I've committed the first-draft release notes for 9.6.4 at
https://git.postgresql.org/pg/commitdiff/03378c4da598840b0520a53580dd7713c95f21c8

(If you prefer to read nicely-marked-up copy, they should be up at
https://www.postgresql.org/docs/devel/static/release-9-6-4.html
in a couple hours from now.)

Please review.
        regards, tom lane



Re: [HACKERS] Draft release notes up for review

From
Jonathan Katz
Date:
Hi Tom,

> On Aug 4, 2017, at 6:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I've committed the first-draft release notes for 9.6.4 at
> https://git.postgresql.org/pg/commitdiff/03378c4da598840b0520a53580dd7713c95f21c8
>
> (If you prefer to read nicely-marked-up copy, they should be up at
> https://www.postgresql.org/docs/devel/static/release-9-6-4.html
> in a couple hours from now.)

Thank you for putting these together.  For the press release, are there any features you (or anyone on -hackers) do you
seeany fixes you would like to highlight? 

I see this one
> Fix potential data corruption when freezing a tuple whose XMAX is a multixact with exactly one still-interesting
member

But I’m unsure how prevalent it is and if it should be highlighted.

Thanks,

Jonathan




Re: [HACKERS] Draft release notes up for review

From
Tom Lane
Date:
Jonathan Katz <jonathan.katz@excoventures.com> writes:
> I see this one
>     > Fix potential data corruption when freezing a tuple whose XMAX is a multixact with exactly one
still-interestingmember 
> But I’m unsure how prevalent it is and if it should be highlighted.

I'm not sure about that either.  I do not think anyone did the legwork
to determine the exact consequences of that bug, or the probability of
someone hitting it in the field.  But I think the latter must be really
low, because we haven't heard any field reports that seem to match up.
        regards, tom lane



Re: [HACKERS] Draft release notes up for review

From
Andres Freund
Date:
Hi Tom,

On 2017-08-04 18:41:12 -0400, Tom Lane wrote:
> I've committed the first-draft release notes for 9.6.4 at
> https://git.postgresql.org/pg/commitdiff/03378c4da598840b0520a53580dd7713c95f21c8

I just pushed a 9.4 specific bugfix. Do you want me to fix up the
release notes after you backpatch the minor release to 9.4, or what's
the best process?

Andres



Re: [HACKERS] Draft release notes up for review

From
Tom Lane
Date:
Andres Freund <andres@anarazel.de> writes:
> I just pushed a 9.4 specific bugfix. Do you want me to fix up the
> release notes after you backpatch the minor release to 9.4, or what's
> the best process?

No sweat, I'll incorporate it when I do the further-back-branch
notes tomorrow.
        regards, tom lane



Re: [HACKERS] Draft release notes up for review

From
Jonathan Katz
Date:
> On Aug 5, 2017, at 5:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Jonathan Katz <jonathan.katz@excoventures.com> writes:
>> I see this one
>>     > Fix potential data corruption when freezing a tuple whose XMAX is a multixact with exactly one
still-interestingmember 
>> But I’m unsure how prevalent it is and if it should be highlighted.
>
> I'm not sure about that either.  I do not think anyone did the legwork
> to determine the exact consequences of that bug, or the probability of
> someone hitting it in the field.  But I think the latter must be really
> low, because we haven't heard any field reports that seem to match up.

OK, thanks for the clarification.  I will follow-up once I have the draft ready for technical review.

Thanks,

Jonathan




Re: [HACKERS] Draft release notes up for review

From
Alvaro Herrera
Date:
Tom Lane wrote:
> Jonathan Katz <jonathan.katz@excoventures.com> writes:
> > I see this one
> >     > Fix potential data corruption when freezing a tuple whose XMAX is a multixact with exactly one
still-interestingmember
 
> > But I’m unsure how prevalent it is and if it should be highlighted.
> 
> I'm not sure about that either.  I do not think anyone did the legwork
> to determine the exact consequences of that bug, or the probability of
> someone hitting it in the field.  But I think the latter must be really
> low, because we haven't heard any field reports that seem to match up.

My assessment is that that bug is extremely hard to hit.  The main
conditions are, according to FreezeMultiXactId, that
1) the tuple must have a multixact xmax; and
2) the update xid must be newer than the cutoff freeze xid;
3) the multixact itself must be older than the cutoff freeze multi.

so the multixact counter needs to go faster than the xid counter (in
terms of who gets past the freeze age first), and a vacuum freeze must
be attempted on that tuple before the update xid becomes freezable.

The consequence is that the infomask, instead of ending up as
    frz->t_infomask = tuple->t_infomask;    frz->t_infomask &= ~HEAP_XMAX_BITS;                    |=
HEAP_XMAX_COMMITTED;   tuple->t_infomask = frz->t_infomask;
 

is instead
    frz->t_infomask = tuple->t_infomask;    frz->t_infomask &= ~HEAP_XMAX_BITS;                    &=
HEAP_XMAX_COMMITTED;   tuple->t_infomask = frz->t_infomask;
 

so any bit other than XMAX_COMMITTED is turned off -- which could be
pretty bad for HEAP_HASNULL, etc.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services