Re: First-draft release notes for next week's releases
От | Josh Berkus |
---|---|
Тема | Re: First-draft release notes for next week's releases |
Дата | |
Msg-id | 53272AF8.9020707@agliodbs.com обсуждение исходный текст |
Ответ на | First-draft release notes for next week's releases (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: First-draft release notes for next week's releases
|
Список | pgsql-hackers |
On 03/17/2014 08:28 AM, Tom Lane wrote: > Greg Stark <stark@mit.edu> writes: >> The error causes some rows to disappear from indexes resulting in >> inconsistent query results on a hot standby depending on whether >> indexes are used. If the standby is subsequently activated or if it >> occurs during recovery after a crash or backup restore it could result >> in unique constraint violations as well. > > Hm ... "rows disappearing from indexes" might make people think that > they could fix or mitigate the damage via REINDEX. That's not really > true though is it? It looks to me like IndexBuildHeapScan will suffer > an Assert failure in an assert-enabled build, or build a bogus index > if not assert-enabled, when it comes across a "heap-only" tuple that > has no parent. First, see suggested text in my first-draft release announcement. Second, if a user has encountered this kind of data corruption on their master (due to crash recovery), how exactly *do* they fix it? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: