Re: Unhappy about API changes in the no-fsm-for-small-rels patch

From: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Date: 2019-04-30 06:12:11
Message-ID: CACPNZCswrm0_yfkM-93zY0igZmTmi-0DsT1s0vHDzDa1fKMLEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 26, 2019 at 11:52 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> As discussed above, we need to issue an
> invalidation for following points: (a) when vacuum finds there is no
> FSM and page has more space now, I think you can detect this in
> RecordPageWithFreeSpace

I took a brief look and we'd have to know how much space was there
before. That doesn't seem possible without first implementing the idea
to save free space locally in the same way the FSM does. Even if we
have consensus on that, there's no code for it, and we're running out
of time.

> (b) invalidation to notify the existence of
> FSM, this can be done both by vacuum and backend.

I still don't claim to be anything but naive in this area, but does
the attached get us any closer?

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
clear-upon-fsm-creation.patch application/octet-stream 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Guo 2019-04-30 06:33:47 Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Previous Message Peter Eisentraut 2019-04-30 06:02:35 Re: generate documentation keywords table automatically