First draft of update announcement

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

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

All,

Updated per feedback. CC'd to Advocacy now for additional corrections.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

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

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

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

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

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

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

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

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