Re: [HACKERS] First draft of update announcement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] First draft of update announcement
Date: 2014-03-18 22:02:15
Message-ID: 29427.1395180135@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Updated per feedback. CC'd to Advocacy now for additional corrections.

A few thoughts:

> The PostgreSQL Global Development Group has released an update to all
> supported version of the database system, including versions 9.3.4, 9.2.8,
> 9.1.13, 9.0.19, and 8.4.20.

By my count, 9.0.17 and 8.4.21 are the correct minor numbers.

> The data corruption issue in PostgreSQL 9.3 affects binary replication
> standbys, servers being recovered from point-in-time-recovery backup, and
> standalone servers which recover from a system crash. The bug causes rows
> to vanish from indexes during recovery due to timing issues with updating
> locks.

Per earlier discussion, I think "vanish from indexes" is a bad choice of
wording here: it will make people think they can recover by REINDEXing,
which is not the case. I haven't got a great alternative wording though;
best I can do offhand is "causes table rows to become unreachable by
index scans", which lacks punch.

Also, although this isn't too important to users, the problem isn't a
"timing issue". How about "... during recovery due to incorrect replay of
tuple locking operations", or some such?

> For this reason, users are encouraged to take a new base backup of each
> of their standby databases after applying the update.

"new base backup for", perhaps? With "of", this sounds like you're
telling people to make backups from the (corrupted) slave servers.

> * Remove ability to execute OVERLAPs with a single argument

There wasn't ever any actual ability to execute such calls; there was only
some code that tried to support the case and failed miserably. I'm not
sure this is worth mentioning in the announcement, really --- but if you
do, this is a poor description because it sounds like we removed a usable
feature.

regards, tom lane

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message gabrielle 2014-03-18 23:25:35 OSCON booth
Previous Message Josh Berkus 2014-03-18 21:42:52 Re: [HACKERS] First draft of update announcement

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-18 22:37:57 Re: Minimum supported version of Python?
Previous Message Josh Berkus 2014-03-18 21:42:52 Re: [HACKERS] First draft of update announcement