Draft release notes up for review

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 see any 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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-interesting member

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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-interesting member

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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-interesting member

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers