Re: Do not check unlogged indexes on standby

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Do not check unlogged indexes on standby
Date: 2019-08-12 22:23:28
Message-ID: CAH2-Wz=Bm6LraEc0jEkOYEiJjNqxqKzjiYXsdt==sp4QqGvgtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 12, 2019 at 2:58 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> Currently, if we check indexes on standby we often get
>
> man-psbpshn0skhsxynd/xiva_xtable_testing_01 R # select bt_index_check('xiva_loadtest.pk_uid');
> ERROR: 58P01: could not open file "base/16453/125407": No such file or directory
>
> I think that we should print warning and that's it. Amcheck should not give false positives.

I agree -- amcheck should just skip over unlogged tables during
recovery, since there is simply nothing to check.

I pushed your patch to all branches that have amcheck just now, so now
we skip over unlogged relations when in recovery, though I made some
revisions.

Your patch didn't handle temp tables/indexes that were created in the
first session correctly -- we must be careful about the distinction
between unlogged tables, and tables that don't require WAL logging
(the later includes temp tables). Also, I thought that it was a good
idea to actively test for the presence of a main fork when we don't
skip (i.e. when the system isn't in recovery and the B-Tree indexes
isn't unlogged) -- we now give a clean report of corruption when that
happens, rather than letting an ambiguous "can't happen" error get
raised by low-level code. This might be possible with system catalog
corruption, for example. Finally, I thought that the WARNING was a bit
strong -- a NOTICE is more appropriate.

Thanks!

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-08-12 22:32:26 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Previous Message Bruce Momjian 2019-08-12 22:23:25 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)