From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Erik Jones <ejones(at)engineyard(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Duplicate key existant/index visibility bug in 9.3.3 |
Date: | 2015-01-26 23:04:31 |
Message-ID: | 18571.1422313471@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Erik Jones <ejones(at)engineyard(dot)com> writes:
> On Jan 26, 2015, at 2:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Maybe. That would require at least one crash recovery to have happened on
>> the server, which Erik seemed to be claiming had not happened. But
>> if there were any crashes then it would possibly fit.
> Definitely nothing recent crash/recovery-wise but digging further back in the logs it looks like there was a crash recovery run startup back on 2014-09-30, which was about a week after this server was created. I suppose its possible that the index has been corrupt since then but only now showing something visible?
Doesn't fit this specific bug fix --- the case it addresses would cause
already-existing rows to become unreachable from the index during crash
recovery. AFAICS that could not create a latent problem for rows inserted
later. Still, this isn't the only bug fixed in 9.3.4/9.3.5. Personally
I'm wondering about c0bd128c81c2b23a1cbc53305180fca51b3b61c3.
I'll try to refrain from asking why a server initdb'd in September wasn't
running 9.3.5 from inception.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-01-26 23:13:55 | Re: Duplicate key existant/index visibility bug in 9.3.3 |
Previous Message | Erik Jones | 2015-01-26 22:54:59 | Re: Duplicate key existant/index visibility bug in 9.3.3 |