On 2014-03-17 10:03:52 -0700, Josh Berkus wrote: > 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.
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. > Second, if a user has encountered this kind of data corruption on their > master (due to crash recovery), how exactly *do* they fix it? Dump/restore is the most obvious candidate. The next best thing I can think of is a noop rewriting ALTER TABLE, that doesn't deal with ctid chains IIRC, in contrast to CLUSTER/VACUUM FULL. 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
