Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, John Naylor <john.naylor@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-07T16:12:37Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2019-05-07 12:04:11 -0400, Tom Lane wrote:
>> I do not think sinval messaging is going to be sufficient to avoid that
>> problem.  sinval is only useful to tell you about changes if you first
>> take a lock strong enough to guarantee that no interesting change is
>> happening while you hold the lock.  We are certainly not going to let
>> writes take an exclusive lock, so I don't see how we could be certain
>> that we've seen an sinval message telling us about FSM status change.

> Sure, but it'll be pretty darn close, rather than there basically not
> being any limit except backend lifetime to how long we might not notice
> that we'd need to switch to the on-disk FSM.

Why do you think there's no limit?  We ordinarily do
RelationGetNumberOfBlocks at least once per query on a table, and
I should think we could fix things so that a "free" side-effect of
that is to get the relcache entry updated with whether an FSM
ought to exist or not.  So I think at worst we'd be one query behind.

			regards, tom lane

Commits

  1. Revert "Avoid the creation of the free space map for small heap relations".

  2. Improve code comments in b0eaa4c51b.

  3. During pg_upgrade, conditionally skip transfer of FSMs.

  4. Add more tests for FSM.

  5. Fix typos in commit 8586bf7ed8.

  6. tableam: introduce table AM infrastructure.

  7. Clear the local map when not used.

  8. Doc: Update the documentation for FSM behavior for small tables.

  9. Make FSM test portable.

  10. Avoid creation of the free space map for small heap relations, take 2.