Re: [PATCH] Full support for index LP_DEAD hint bits on standby

From: Antonin Houska <ah(at)cybertec(dot)at>
To: Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Full support for index LP_DEAD hint bits on standby
Date: 2021-05-06 07:04:44
Message-ID: 41763.1620284684@antos
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm trying to review the patch, but not sure if I understand this problem,
please see my comment below.

Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> wrote:

> Oh, I just realized that it seems like I was too naive to allow
> standby to set LP_DEAD bits this way.
> There is a possible consistency problem in the case of low
> minRecoveryPoint value (because hint bits do not move PageLSN
> forward).
>
> Something like this:
>
> LSN=10 STANDBY INSERTS NEW ROW IN INDEX (index_lsn=10)
> <-----------minRecoveryPoint will go here
> LSN=20 STANDBY DELETES ROW FROM HEAP, INDEX UNTACHED (index_lsn=10)

Why doesn't minRecoveryPoint get updated to 20? IMO that should happen by
replaying the commit record. And if the standby happens to crash before the
commit record could be replayed, no query should see the deletion and thus no
hint bit should be set in the index.

> REPLICA SCANS INDEX AND SET hint bits (index_lsn=10)
> INDEX IS FLUSHED (minRecoveryPoint=index_lsn=10)
> CRASH
>
> On crash recovery, a standby will be able to handle queries after
> LSN=10. But the index page contains hints bits from the future
> (LSN=20).
> So, need to think here.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-05-06 07:23:02 Re: .ready and .done files considered harmful
Previous Message Amit Kapila 2021-05-06 07:02:56 Re: Replication slot stats misgivings