RE: Protect syscache from bloating with negative cache entries - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Protect syscache from bloating with negative cache entries
Date
Msg-id 0A3221C70F24FB45833433255569204D1FB9D860@G01JPEXMBYT05
Whole thread Raw
In response to Re: Protect syscache from bloating with negative cache entries  ('Bruce Momjian' <bruce@momjian.us>)
Responses Re: Protect syscache from bloating with negative cache entries
List pgsql-hackers
From: 'Bruce Momjian' [mailto:bruce@momjian.us]
> I think, in general, smaller is better, as long as making something
> smaller doesn't remove data that is frequently accessed.  Having a timer
> to expire only old entries seems like it accomplished this goal.
> 
> Having a minimum size and not taking it to zero size makes sense if we
> know we will need certain entries like pg_class in the next query.
> However, if the session is idle for hours, we should just probably
> remove everything, so maybe the minimum doesn't make sense --- just
> remove everything.

That's another interesting idea.  A somewhat relevant feature is Oracle's "ALTER SYSTEM FLUSH SHARED_POOL".  It flushes
alldictionary cache, library cache, and SQL plan entries.  The purpose is different: not to release memory, but to
defragmentthe shared memory.
 


> I don't think other DBMSs are a good model since they have a reputation
> for requiring a lot of tuning --- tuning that we have often automated.

Yeah, I agree that PostgreSQL is easier to use in many aspects.

On the other hand, although I hesitate to say this (please don't get upset...), I feel PostgreSQL is a bit too loose
aboutmemory usage.  To my memory, PostgreSQL crashed OS due to OOM in our user environments:
 

* Creating and dropping temp tables repeatedly in a stored PL/pgSQL function.  This results in infinite
CacheMemoryContextbloat.  This is referred to at the beginning of this mail thread.
 
Oracle and MySQL can limit the size of the dictionary cache.

* Each pair of SAVEPOINT/RELEASE leaves 8KB of CurTransactionContext.  The customer used psqlODBC to run a batch app,
whichran millions of SQL statements in a transaction.  psqlODBC wraps each SQL statement with SAVEPOINT and RELEASE by
default.
I guess this is what caused the crash of AWS Aurora in last year's Amazon Prime Day.

* Setting a large value to work_mem, and then run many concurrent large queries.
Oracle can limit the total size of all sessions' memory with PGA_AGGREGATE_TARGET parameter.


We all have to manage things within resource constraints.  The DBA wants to make sure the server doesn't overuse memory
toavoid crash or slowdown due to swapping.  Oracle does it, and another open source database, MySQL, does it too.
PostgreSQLdoes it with shared_buffers, wal_buffers, and work_mem (within a single session).  Then, I thought it's
naturalto do it with catcache/relcache/plancache.
 


Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Some thoughts on NFS
Next
From: Thomas Munro
Date:
Subject: Re: Change of email address