From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: oddity in initdb probing of max_connections/shared_buffers |
Date: | 2016-07-04 15:11:25 |
Message-ID: | 19758.1467645085@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <stark(at)mit(dot)edu> writes:
> I happened to notice a bit of an inconsistency in the way initdb
> probes max_connections and shared_buffers.
> This line in the shared_buffers test:
> /* Use same amount of memory, independent of BLCKSZ */
> test_buffs = (trial_bufs[i] * 8192) / BLCKSZ;
> has no equivalent in the max_connections test. As a result
> max_connections is tested with 10 buffers per connection regardless of
> BLCKSZ.
> Is this intentional? Is the idea that Postgres can't function properly
> without being able to read from 10 files concurrently regardless of
> block size? Or is it an unintentional holdover from before the line
> above was added for the shared_buffers tests?
I think it's intentional; the minimum number of buffers needed per
session doesn't really vary with BLCKSZ, but rather with code structure
(ie, how many buffer pins a query might take at once). Still, some
comments documenting that a little better wouldn't be a bad thing.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas 'ads' Scherbaum | 2016-07-04 16:17:34 | Re: to_date_valid() |
Previous Message | Matt Kelly | 2016-07-04 15:04:28 | Re: Cluster on NAS and data center. |