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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
