From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First-draft release notes for next week's releases |
Date: | 2014-03-17 17:03:52 |
Message-ID: | 53272AF8.9020707@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/17/2014 08:28 AM, Tom Lane wrote:
> Greg Stark <stark(at)mit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-03-17 17:08:16 | Re: First-draft release notes for next week's releases |
Previous Message | Andres Freund | 2014-03-17 17:03:49 | Re: warning when compiling utils/tqual.h |