Re: oddity in initdb probing of max_connections/shared_buffers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: oddity in initdb probing of max_connections/shared_buffers
Date
Msg-id 19758.1467645085@sss.pgh.pa.us
Whole thread Raw
In response to oddity in initdb probing of max_connections/shared_buffers  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.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



pgsql-hackers by date:

Previous
From: Matt Kelly
Date:
Subject: Re: Cluster on NAS and data center.
Next
From: Andreas 'ads' Scherbaum
Date:
Subject: Re: to_date_valid()