On 03/17/2014 08:28 AM, Tom Lane wrote: > Greg Stark <st...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
