From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 10.5 but not 10.4: backend startup during reindex system: could not read block 0 in file "base/16400/..": read only 0 of 8192 bytes |
Date: | 2018-08-30 21:30:30 |
Message-ID: | 26526.1535664630@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> On Wed, Aug 29, 2018 at 11:35:51AM -0400, Tom Lane wrote:
>> As far as we can tell, that bug is a dozen years old, so it's not clear
>> why you find that you can reproduce it only in 10.5. But there might be
>> some subtle timing change accounting for that.
> It seems to me there's one root problem occurring in (at least) two slightly
> different ways. The issue/symptom that I've been seeing occurs in 10.5 but not
> 10.4, and specifically at commit 2ce64ca, but not before.
Yeah, as you probably saw in the other thread, we later realized that
2ce64ca created an additional pathway for ScanPgRelation to recurse;
a pathway that's evidently easier to hit than the pre-existing ones.
I note that both of your stack traces display ScanPgRelation recursion,
so I'm feeling pretty confident that what you're seeing is the same
thing.
But, as Andres says, it'd be great if you could confirm whether the
draft patches fix it for you.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-30 21:38:36 | Re: Startup cost of sequential scan |
Previous Message | Tom Lane | 2018-08-30 21:19:28 | Re: pg_verify_checksums and -fno-strict-aliasing |