Re: Draft release notes for 9.3.2

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-12-01 18:56:19 -0500, Tom Lane wrote:
>> * is it useful to go into more detail than this about the data corruption
>> bugs? It's not clear to me that we can say more than "vacuum and re-clone
>> your standbys" as far as recovery actions go, at least not within the
>> couple of sentences that we traditionally allow for a release note item.

> I think it might be worth mentioning that (parts) of the data are
> potentially recoverable without too much effort in all of the bugs.

I thought about that but was afraid that it'd come off like a commercial
for data recovery services, which didn't seem appropriate. People who
need this type of service can get advice on the mailing lists, anyway.

>> * is there anything important to be said about the fourth and fifth bullet
>> points ("Fix bugs in setting the visibility-map bit for an empty page"

> I doubt it's worth mentioning that one. Pretty much the only possible
> consequence is hitting an Assert() in assert enabled builds in a pretty
> rare scenario. There's no data corruption.

OK, removed. We usually mention Assert-fixing commits but this update
certainly has enough other reasons to get installed :-(

>> and "Fix multiple bugs in update chain traversal")?

> These have quite some possible consequences though. Not sure how to
> describe it in few words, but it could lead to updating, locking or
> returning the wrong row (by following into a different ctid chain),
> unneccessary deadlocks (by unneccesarily waiting for an entire
> multixact's member, instead of just the updater), missed and superflous
> serialization failures in repeatable read and, slightly differently, in
> serializable. All need concurrency to manifest.

I put in a little bit here.

> Not sure whether f5f92bdc44ffdf577244e0d055825cacd0cdea10,
> d9484ab5f3cbcfea64536fec333723f9aa4c0b2c shouldn't be mentioned
> separately, especially the first could cause autovacuum to crazily spawn
> children without ever actually doing anything useful.

Agreed, significant autovacuum activity is a separate symptom, so it
seems worth mentioning separately.

> I think Sergey's and Jeff's fix
> (4c697d8f4845823a8af67788b219ffa4516ad14c) deserves its own
> headline.

Yeah, I had lumped it with the "wrong relfrozenxid accounting" issue
but again the symptom is different.

> <para>
> Fix initialization of <filename>pg_clog</> and
> <filename>pg_subtrans</>
> during hot standby startup (Andres Freund)
> </para>
> I think Heikki spent a fair amount of time looking at the code, so it
> seems fair to also name him as well..

Done.

> Maybe we should mention that hot_standby=on is a prerequisite?

Well, it already says hot standby, but I repeated that term in the
body to emphasize it.

> <para>
> This avoids ever-increasing disk space consumption in hot standby
> mode.
> </para>
> It's not really related to hot standby - anything that never comes out
> of crash recovery is affected. We sometime should come up with a
> coherent name that covers HS, SR, PITR, warm standbys et al...

OK, I said "standby server" instead, which should cover the most
interesting cases.

> Should the strerror() improvements be mentioned
> (e3480438e89f74019f271b1b5501bb9eed2e0d2a)?

I intentionally left that out because it seemed like a reasonable
explanation would take more space than was justified.

Thanks for looking at the notes!

regards, tom lane