Josh Berkus <j...@agliodbs.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
