From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | sk(at)zsrv(dot)org, pgsql-bugs(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Subject: | Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY |
Date: | 2022-08-15 23:39:24 |
Message-ID: | 20220815233924.5jlus3ukkqmmts5g@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On 2022-08-03 14:23:34 +0000, PG Bug reporting form wrote:
> I think some process may have loaded btree metapage (page 0) into shared
> buffers prior the end of _bt_load. In this case, the error is reproduced
> (14.4, 14 STABLE, HEAD):
>
> create extension pageinspect;
> create table test as select generate_series(1,1e4) as id;
> create index test_id_idx on test(id);
> # prepare gdb for this backend with breakpoint on _bt_uppershutdown
> reindex index concurrently test_id_idx ;
Worth noting that this doesn't even require reindex concurrently, it's also an
issue for CIC.
The problem basically is that once the first non-meta page from the btree is
written (e.g. _bt_blwritepage() calling smgrextend()), concurrent sessions can
read in the metapage (and potentially other pages that are also zero filled)
into shared_buffers. at the end of _bt_uppershutdown() we'll write the
metapage to disk, bypassing shared buffers. And boom, the all-zeroes version
read into memory earlier is suddenly out of date.
The easiest fix is likely to force all buffers to be forgotten at the end of
index_concurrently_build() or such. I don't immediately see a nicer way to fix
this, we can't just lock the new index relation exclusively.
We could of course also stop bypassing s_b for CIC/RIC, but that seems mighty
invasive for a bugfix.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-08-15 23:56:40 | Re: BUG #17568: unexpected zero page at block 0 during REINDEX CONCURRENTLY |
Previous Message | Andres Freund | 2022-08-15 23:01:35 | Re: BUG #17586: Look like there are an another bug in REINDEX INDEX CONCURRENTLY of pg_toast indexes |