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.

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

Reply via email to