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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: POC: Cleaning up orphaned files using undo logs
Следующее
От: John Naylor
Дата:
Сообщение: Re: Unhappy about API changes in the no-fsm-for-small-rels patch