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
|
Список | 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 по дате отправления: