Horton

Re: [HACKERS] WAL logging problem in 9.4.3?

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Dmitry Dolgov <9erthalion6@gmail.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, hlinnaka <hlinnaka@iki.fi>, Michael Paquier <michael@paquier.xyz>
Date: 2019-12-09T15:56:40Z
Lists: pgsql-hackers 
On Mon, Dec 9, 2019 at 4:04 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> Yeah, only 0.5GB of shared_buffers makes the default value of
> wal_buffers reach to the heaven. I think I can take numbers on that
> condition. (I doubt that it's meaningful if I increase only
> wal_buffers manually.)

Heaven seems a bit exalted, but I think we really only have a formula
because somebody might have really small shared_buffers for some
reason and be unhappy about us gobbling up a comparatively large
amount of memory for WAL buffers. The current limit means that normal
installations get what they need without manual tuning, and small
installations - where performance presumably sucks anyway for other
reasons - keep a small memory footprint.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Add perl2host call missing from a new test file.

  2. Skip WAL for new relfilenodes, under wal_level=minimal.

  3. Revert "Skip WAL for new relfilenodes, under wal_level=minimal."

  4. Back-patch log_newpage_range().

  5. During heap rebuild, lock any TOAST index until end of transaction.

  6. In log_newpage_range(), heed forkNum and page_std arguments.

  7. Back-patch src/test/recovery and PostgresNode from 9.6 to 9.5.

  8. Reduce pg_ctl's reaction time when waiting for postmaster start/stop.

  9. Accelerate end-of-transaction dropping of relations

  10. Redesign the planner's handling of index-descent cost estimation.

  11. Make TRUNCATE do truncate-in-place when processing a relation that was created