oddity in initdb probing of max_connections/shared_buffers

From: Greg Stark <stark(at)mit(dot)edu>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: oddity in initdb probing of max_connections/shared_buffers
Date: 2016-07-04 11:10:57
Message-ID: CAM-w4HNch+7+jUvBQmasCR5h0B-rGS7TJFa6YnfHf4i3WyVrkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
greg

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Borodin 2016-07-04 11:22:37 Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Previous Message Krzysztof Kaczkowski 2016-07-04 10:36:02 Re: Cluster on NAS and data center.