Re: [PATCH] Full support for index LP_DEAD hint bits on standby
От | Antonin Houska |
---|---|
Тема | Re: [PATCH] Full support for index LP_DEAD hint bits on standby |
Дата | |
Msg-id | 41763.1620284684@antos обсуждение исходный текст |
Ответ на | Re: [PATCH] Full support for index LP_DEAD hint bits on standby (Michail Nikolaev <michail.nikolaev@gmail.com>) |
Ответы |
Re: [PATCH] Full support for index LP_DEAD hint bits on standby
|
Список | 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.nikolaev@gmail.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
В списке pgsql-hackers по дате отправления: