On 2014-03-17 13:42:59 -0400, Tom Lane wrote:
> Andres Freund <and...@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 exclusion constraint are also
* 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."


Andres Freund

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

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

Reply via email to