Thread: First draft of update announcement
... attached. Please correct! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Attachment
2014-03-17 13:24 GMT+09:00 Josh Berkus <josh@agliodbs.com>: > ... attached. Please correct! A couple of drive-by corrections: "each of their standy databases" standy -> standby "Prevent erroneous operator push-down in pgsql_fdw" pgsql_fdw -> postgres_fdw Regards Ian Barwick
All, Updated per feedback. CC'd to Advocacy now for additional corrections. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Attachment
Josh Berkus <josh@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
On 03/18/2014 03:02 PM, Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: >> Updated per feedback. CC'd to Advocacy now for additional corrections. > > A few thoughts: Changes incorporated. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 2014-03-18, 2:42 PM, Josh Berkus wrote: > Other PostgreSQL 9.3 only fixes in this update include: > > * Add read-only data_checksum parameter I recall being told last fall that this would not be added to 9.3.x (9.3.1 at the time I think) and only to 9.4.x because such a feature addition was something only allowed for major releases and not minor ones which were just supposed to be security and bug fixes. So what changed that it is added in 9.3.x after all? -- Darren Duncan
On 03/19/2014 02:16 PM, Darren Duncan wrote: > On 2014-03-18, 2:42 PM, Josh Berkus wrote: >> Other PostgreSQL 9.3 only fixes in this update include: >> >> * Add read-only data_checksum parameter > > I recall being told last fall that this would not be added to 9.3.x > (9.3.1 at the time I think) and only to 9.4.x because such a feature > addition was something only allowed for major releases and not minor > ones which were just supposed to be security and bug fixes. > > So what changed that it is added in 9.3.x after all? Enough people reported operational problems with not having the parameter. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com