On 2014-03-17 13:42:59 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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
exclusionconstraint 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
withoutforeign keys. Maybe: "can arise when a table row that has been updated is row locked; that can e.g. happen when
foreignkeys are used."
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services