Обсуждение: oddity in initdb probing of max_connections/shared_buffers

Поиск
Список
Период
Сортировка

oddity in initdb probing of max_connections/shared_buffers

От
Greg Stark
Дата:
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



Re: oddity in initdb probing of max_connections/shared_buffers

От
Tom Lane
Дата:
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