Re: [HACKERS] shared memory based stat collector (was: Sharing recordtypmods between backends)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] shared memory based stat collector (was: Sharing recordtypmods between backends)
Дата
Msg-id CA+TgmoZ7jH4GE-PX=MRxr=7HEg-LXpNtS48yP044zQydZrreaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] shared memory based stat collector (was: Sharingrecord typmods between backends)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [HACKERS] shared memory based stat collector (was: Sharing record typmods between backends)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Aug 14, 2017 at 7:16 PM, Alvaro Herrera
<alvherre@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Orphaned files in base/[oid]
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks