Re: First-draft release notes for next week's releases

On 2014-03-17 13:42:59 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2014-03-17 10:03:52 -0700, Josh Berkus wrote:
> >> First, see suggested text in my first-draft release announcement.
>
> > I don't think that text is any better, it's imo even wrong:
> > "The bug causes rows to vanish from indexes during recovery due to
> > simultaneous updates of rows on both sides of a foreign key."
>
> > Neither is a foreign key, nor simultaneous updates, nor both sides a
> > prerequisite.
>
> What I've got at the moment is
>
> This error caused updated rows to disappear from indexes, resulting
> in inconsistent query results depending on whether an index scan was
> used. Subsequent processing could result in unique-key violations,
> since the previously updated row would not be found by later index
> searches. Since this error is in WAL replay, it would only manifest
> during crash recovery or on standby servers. The improperly-replayed
> case can arise when a table row that is referenced by a foreign-key
> constraint is updated concurrently with creation of a
> referencing row.
>
> OK, or not? The time window for bikeshedding this is dwindling rapidly.

That's much better, yes. Two things:

* I'd change the warning about unique key violations into a more general
one about constraints. Foreign key and exclusion constraint are also
affected...
* I wonder if we should make the possible origins a bit more
general as it's perfectly possible to trigger the problem without
foreign keys. Maybe: "can arise when a table row that has been updated
is row locked; that can e.g. happen when foreign keys are used."

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services