Re: oddity in initdb probing of max_connections/shared_buffers
От
Tom Lane
Тема
Re: oddity in initdb probing of max_connections/shared_buffers
Дата
Msg-id
19758.1467645085@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
oddity in initdb probing of max_connections/shared_buffers Greg Stark <stark@mit.edu>
Re: oddity in initdb probing of max_connections/shared_buffers Tom Lane <tgl@sss.pgh.pa.us>
Greg Stark 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 по дате отправления