On Sat, Apr 26, 2014 at 11:20:56AM -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > What I think it's necessary for is at least:
>
> > * Move the buffer content lock inline into to the buffer descriptor,
> > while still fitting into one cacheline.
> > * lockless/atomic Pin/Unpin Buffer.
>
> TBH, that argument seems darn weak, not to mention probably applicable
> only to current-vintage Intel chips. And you have not proven that
> narrowing the backend ID is necessary to either goal, even if we
> accepted that these goals were that important.
>
> While I agree with you that it seems somewhat unlikely we'd ever get
> past 2^16 backends, these arguments are not nearly good enough to
> justify a hard-wired limitation.
I'm satisfied with the arguments Andres presented, which I presume were weak
only because he didn't expect a staunch defense of max_connections=70000 use.
The new restriction will still permit settings an order of magnitude larger
than current *worst* practice and 2-3 orders of magnitude larger than current
good practice. If the next decade sees database server core counts grow by
two orders of magnitude or sees typical cache architectures change enough to
make the compactness irrelevant, we'll have the usual opportunities to react.
Today, the harm from contention on buffer headers totally eclipses the benefit
of allowing max_connections=70000. There's no cause to predict a hardware
development radical enough to change that conclusion.
Sure, let's not actually commit a patch to impose this limit until the first
change benefiting from doing so is ready to go. There remains an opportunity
to evaluate whether that beneficiary change is better done a different way.
By having this thread to first settle that the new max_connections limit is
essentially okay, the eventual thread concerning lock-free pin manipulation
need not inflate from discussion of this side issue.
On Sat, Apr 26, 2014 at 11:22:39AM -0400, Tom Lane wrote:
> And next week when we need some other field in a buffer header,
> what's going to happen? If things are so tight that we need to
> shave a few bits off backend IDs, the whole thing is a house of
> cards anyway.
The buffer header has seen one change in nine years. Making it an inviting
site for future patches is not important.
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com