Date: Wed, 7 Mar 2018 08:01:38 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: andres@anarazel.de, robertmhaas@gmail.com, tgl@sss.pgh.pa.us,
	michael.paquier@gmail.com, david@pgmasters.net,
	Jim.Nasby@bluetreble.com, craig@2ndquadrant.com,
	pgsql-hackers@postgresql.org
Subject: Re: Protect syscache from bloating with negative cache entries
Message-ID: <20180307110138.qp3wsav7ka43qrlj@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20180307.172545.231972323.horiguchi.kyotaro@lab.ntt.co.jp>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

The thing that comes to mind when reading this patch is that some time
ago we made fun of other database software, "they are so complicated to
configure, they have some magical settings that few people understand
how to set".  Postgres was so much better because it was simple to set
up, no magic crap.  But now it becomes apparent that that only was so
because Postgres sucked, ie., we hadn't yet gotten to the point where we
*needed* to introduce settings like that.  Now we finally are?

I have to admit being a little disappointed about that outcome.

I wonder if this is just because we refuse to acknowledge the notion of
a connection pooler.  If we did, and the pooler told us "here, this
session is being given back to us by the application, we'll keep it
around until the next app comes along", could we clean the oldest
inactive cache entries at that point?  Currently they use DISCARD for
that.  Though this does nothing to fix hypothetical cache bloat for
pg_dump in bug #14936.

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