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

From Amit Kapila
Subject Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Date
Msg-id CAA4eK1+fu3DDoybc+P4HfD7ms0vbgL2oqZ7Y45dmYrjHshP04A@mail.gmail.com
Whole thread Raw
In response to Re: Unhappy about API changes in the no-fsm-for-small-rels patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unhappy about API changes in the no-fsm-for-small-rels patch
List pgsql-hackers
On Wed, Apr 17, 2019 at 9:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andres Freund <andres@anarazel.de> writes:
> > On 2019-04-17 15:49:29 +0530, Amit Kapila wrote:
> >> OTOH, if we want to extend it later for whatever reason to a relation
> >> level cache, it shouldn't be that difficult as the implementation is
> >> mostly contained in freespace.c (fsm* functions) and I think the
> >> relation is accessible in most places.  We might need to rip out some
> >> calls to clearlocalmap.
>
> > But it really isn't contained to freespace.c. That's my primary
> > concern. You added new parameters (undocumented ones!),
> > FSMClearLocalMap() needs to be called by callers and xlog, etc.
>
> Given where we are in the release cycle, and the major architectural
> concerns that have been raised about this patch, should we just
> revert it and try again in v13, rather than trying to fix it under
> time pressure?
>

I respect and will follow whatever will be the consensus after
discussion.  However, I request you to wait for some time to let the
discussion conclude.  If we can't get to an
agreement or one of John or me can't implement what is decided, then
we can anyway revert it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Next
From: Peter Eisentraut
Date:
Subject: Re: Fix handling of unlogged tables in FOR ALL TABLES publications