bgwriter_lru_maxpages limits in PG 10 sample conf
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t40154psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 04:37 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t40154_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t40154_1 && git checkout t40154_1Patchset v1 (message #1) is on t40154_1
Hello
We increased bgwriter_lru_maxpages limit in 10 release [1]. Docs now are changed correctly but in REL_10_STABLE postgresql.conf.sample we still have comment "0-1000 max buffers written/round".
Master (and REL_11_STABLE) was updated later in 611fe7d4793ba6516e839dc50b5319b990283f4f, but not REL_10. I think we need backpatch this line.
* /messages/by-id/f6e58a22-030b-eb8a-5457-f62fb08d701c@BlueTreble.com
regards, Sergei
On Wed, Feb 20, 2019 at 5:53 AM Sergei Kornilov <sk@zsrv.org> wrote:
We increased bgwriter_lru_maxpages limit in 10 release [1]. Docs now are changed correctly but in REL_10_STABLE postgresql.conf.sample we still have comment "0-1000 max buffers written/round".
Master (and REL_11_STABLE) was updated later in 611fe7d4793ba6516e839dc50b5319b990283f4f, but not REL_10. I think we need backpatch this line.
I'm a bit reluctant to whack postgresql.conf around in back-branches
because sometimes that makes funny things happen when somebody
upgrades, e.g. via RPM. I don't remember exactly what happens but I
think typically either the new file overwrites the existing file which
gets moved to something like postgresql.conf.rpmsave or the new file
is written into postgresql.conf.rpmnew instead of the original
location. I don't think it's worth making stuff like that happen for
the sake of a comment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hello
I'm a bit reluctant to whack postgresql.conf around in back-branches
because sometimes that makes funny things happen when somebody
upgrades, e.g. via RPM.
If i remember correctly both deb and rpm packages will ask user about config difference.
But good point, comment change is too small difference. I am a bit late, good time for such change was before last minor release (we add data_sync_retry and config was changed anyway).
regards, Sergei
On Wed, Feb 20, 2019 at 11:54:25PM +0300, Sergei Kornilov wrote:
Hello
I'm a bit reluctant to whack postgresql.conf around in back-branches
because sometimes that makes funny things happen when somebody
upgrades, e.g. via RPM.If i remember correctly both deb and rpm packages will ask user about config difference.
But good point, comment change is too small difference. I am a bit late, good time for such change was before last minor release (we add data_sync_retry and config was changed anyway).
The other issue is that you will change share/postgresql.conf.sample,
but not $PGDATA/postgresql.conf until initdb is run, meaning if someone
diffs the two files, they will see differences that they did not make.
Making defaults more accurate is not worth that confusion.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +Hello
postgresql.conf.sample was changed recently in REL_10_STABLE (commit ab1d9f066aee4f9b81abde6136771debe0191ae8)
So config will be changed in next minor release anyway. We have another reason to not fix bgwriter_lru_maxpages comment?
regards, Sergei
On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote:
Hello
postgresql.conf.sample was changed recently in REL_10_STABLE (commit ab1d9f066aee4f9b81abde6136771debe0191ae8)
So config will be changed in next minor release anyway. We have another reason to not fix bgwriter_lru_maxpages comment?
Frankly, I was surprised postgresql.conf.sample was changed in a back
branch since it will cause people who diff $PGDATA/postgresql.conf with
share/postgresql.conf.sample to see differences they didn't make.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On 2019-Mar-04, Bruce Momjian wrote:
On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote:
Hello
postgresql.conf.sample was changed recently in REL_10_STABLE (commit ab1d9f066aee4f9b81abde6136771debe0191ae8)
So config will be changed in next minor release anyway. We have another reason to not fix bgwriter_lru_maxpages comment?Frankly, I was surprised postgresql.conf.sample was changed in a back
branch since it will cause people who diff $PGDATA/postgresql.conf with
share/postgresql.conf.sample to see differences they didn't make.
I think the set of people that execute diffs of their production conf
file against the sample file to be pretty small -- maybe even empty. If
you're really interested in knowing the changes you've done, you're more
likely to use a version control system on the file anyway.
--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Mar 5, 2019 at 12:24:14AM -0300, Alvaro Herrera wrote:
On 2019-Mar-04, Bruce Momjian wrote:
On Thu, Feb 28, 2019 at 10:28:44AM +0300, Sergei Kornilov wrote:
Hello
postgresql.conf.sample was changed recently in REL_10_STABLE (commit ab1d9f066aee4f9b81abde6136771debe0191ae8)
So config will be changed in next minor release anyway. We have another reason to not fix bgwriter_lru_maxpages comment?Frankly, I was surprised postgresql.conf.sample was changed in a back
branch since it will cause people who diff $PGDATA/postgresql.conf with
share/postgresql.conf.sample to see differences they didn't make.I think the set of people that execute diffs of their production conf
file against the sample file to be pretty small -- maybe even empty. If
you're really interested in knowing the changes you've done, you're more
likely to use a version control system on the file anyway.
Well, if this is true, then we should all agree to backpatch to
postgresql.conf.sample more often.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +