Re: Unhappy about API changes in the no-fsm-for-small-rels patch - Mailing list pgsql-hackers

From John Naylor
Subject Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Date
Msg-id CACPNZCuC=Ozd1BsB+jaYDfEuWW0DFoU08iaFyCyUBDe6N3V+1Q@mail.gmail.com
Whole thread Raw
In response to Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs
Next
From: John Naylor
Date:
Subject: Re: Unhappy about API changes in the no-fsm-for-small-rels patch