Re: Unhappy about API changes in the no-fsm-for-small-rels patch

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Дата
Msg-id CACPNZCtKRXUs0w4w_E68v=6w5RcfpzT5yB5ERNQfRqbtsxNXMg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, May 2, 2019 at 2:31 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> @@ -776,7 +776,10 @@ fsm_extend(Relation rel, BlockNumber fsm_nblocks)
>   if ((rel->rd_smgr->smgr_fsm_nblocks == 0 ||
>   rel->rd_smgr->smgr_fsm_nblocks == InvalidBlockNumber) &&
>   !smgrexists(rel->rd_smgr, FSM_FORKNUM))
> + {
>   smgrcreate(rel->rd_smgr, FSM_FORKNUM, false);
> + fsm_clear_local_map(rel);
> + }
>
> I think this won't be correct because when we call fsm_extend via
> vacuum the local map won't be already existing, so it won't issue an
> invalidation call.  Isn't it better to directly call
> CacheInvalidateRelcache here to notify other backends that their local
> maps are invalid now?

Yes, you're quite correct.

-- 
John Naylor                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Failure in contrib test _int on loach