Thread: [HACKERS] Draft release notes up for review
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
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
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
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
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
> 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
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