Re: shared memory based stat collector (was: Sharing record typmods between backends)

On Mon, Aug 14, 2017 at 7:16 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
>> Yeah, and the other question -- which Thomas asked before you
>> originally committed originally, and which I just now asked again is
>> "Why in the world are you using DSA for this at all?". There are
>> serious problems with that which both he and I have pointed out, and
>> you haven't explained why it's a good idea at any point, AFAICT.
>
> The main reason is that I envision that the workitem stuff will be used
> for other things in the future than just brin summarization, and it
> seemed a lame idea to just use a fixed-size memory area in the standard
> autovacuum shared memory area. I think unbounded growth is of course
> going to be bad. The current coding doesn't allow for any growth beyond
> the initial fixed size, but it's easier to extend the system from the
> current point rather than wholly changing shared memory usage pattern
> while at it.

I don't accept that argument. All the current code does is allocate
one fixed-size chunk of memory in DSA, so the whole pattern would have
to be changed *anyway* if you wanted to grow the array. It's not
like you are allocating the items one-by-one.

I really, really strongly encourage you to rip the use of DSA out here
entirely. It is reducing the reliability of a critical part of the
system for no actual benefit other than speculation that this is going
to be better in the future, and it adds a bunch of failure cases that
we could just as well live without.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company