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 | CACPNZCuC=Ozd1BsB+jaYDfEuWW0DFoU08iaFyCyUBDe6N3V+1Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unhappy about API changes in the no-fsm-for-small-rels patch (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Tue, Apr 30, 2019 at 6:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Apr 30, 2019 at 2:24 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > insert into atacc1 values (21, 22, 23); > > +ERROR: could not read block 0 in file "base/16384/31379": read only > > 0 of 8192 bytes > > > > I have analysed this failure. Seems that we have not reset the > > rel->fsm_local_map while truncating the relation pages by vacuum > > (lazy_truncate_heap). So when next time while accessing it we are > > getting the error. I think we need a mechanism to invalidate this > > when we truncate the relation pages. I am not sure whether we should > > invalidate the relcache entry here or just reset the > > rel->fsm_local_map? > > > > Thanks, this appears to be the missing case where we need to > invalidate the cache. So, as discussed above if we issue invalidation > call (in RecordPageWithFreeSpace) when the page becomes empty, then we > shouldn't encounter this. John, can we try this out and see if the > failure goes away? I added a clear/inval call in RecordPageWithFreeSpace and the failure goes away. Thanks for the analysis, Dilip! -- John Naylor https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: