Re: [HACKERS] pg_shmem_allocations view

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] pg_shmem_allocations view
Date: 2019-12-18 17:06:32
Message-ID: 7261.1576688792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Dec 18, 2019 at 10:59 AM Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message gmail Vladimir Koković 2019-12-18 17:28:07 Restore backup file "with oids"
Previous Message Robert Haas 2019-12-18 16:50:51 Re: [HACKERS] pg_shmem_allocations view