Re: [HACKERS] pg_shmem_allocations view
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_shmem_allocations view |
Дата | |
Msg-id | 7261.1576688792@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_shmem_allocations view (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] pg_shmem_allocations view
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Dec 18, 2019 at 10:59 AM Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >> Can we please stop splitting this error message in two? >> >> + errmsg("materialize mode required, but it is not " \ >> + "allowed in this context"))); >> >> (What's with the newline escape there anyway?) > That message is like that everywhere in the tree, including the > escape, except for a couple of instances in contrib which deviate. If > you want to go change them all, feel free, and I'll adjust this to > match the then-prevailing style. I agree with Alvaro that that is *not* project style, particularly not the newline escape. Like Robert, I'm not quite fussed enough to go change it, but +1 if Alvaro wants to. > It seems to me that you could plausibly define this view to show > either (a) the amount of space that the caller actually tried to > allocate or (b) the amount of space that the allocator decided to > allocate, after padding, and it's not obvious that (b) is a better > definition than (a). > That having been said, you're correct that the padding space is > currently reported as <anonymous>, and that does seem wrong. It seems like it'd be worth subdividing "<anonymous>" into the actual anonymous allocations and the allocator overhead (which is both padding and whatever the shmem allocator itself eats). Maybe call the latter "<overhead>". After which, I'd be tempted to call the free space "<free>" rather than giving it a null name. regards, tom lane
В списке pgsql-hackers по дате отправления: