Re: First-draft release notes for next week's releases
От | Tom Lane |
---|---|
Тема | Re: First-draft release notes for next week's releases |
Дата | |
Msg-id | 23634.1395078179@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: First-draft release notes for next week's releases (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: First-draft release notes for next week's releases
|
Список | pgsql-hackers |
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 whetheran index scan was used. Subsequent processing could result in unique-key violations, since the previouslyupdated 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 thatis 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. regards, tom lane
В списке pgsql-hackers по дате отправления: