Re: Add tracking of backend memory allocated to pg_stat_activity

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Reid Thompson <reid(dot)thompson(at)crunchydata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add tracking of backend memory allocated to pg_stat_activity
Date: 2022-08-31 17:05:55
Message-ID: 20220831170555.GW31833@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 31, 2022 at 12:03:06PM -0400, Reid Thompson wrote:
> Hi Hackers,
>
> Attached is a patch to
> Add tracking of backend memory allocated to pg_stat_activity

> + proargmodes => '{i,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o}',

In the past, there was concern about making pg_stat_activity wider by
adding information that's less-essential than what's been there for
years. This is only an int64, so it's not "wide", but I wonder if
there's another way to expose this information? Like adding backends to
pg_get_backend_memory_contexts() , maybe with another view on top of
that ?

+ * shown allocated in pgstat_activity when the creator destroys the

pg_stat

> + * Posix creation calls dsm_impl_posix_resize implying that resizing
> + * occurs or may be added in the future. As implemented
> + * dsm_impl_posix_resize utilizes fallocate or truncate, passing the
> + * whole new size as input, growing the allocation as needed * (only
> + * truncate supports shrinking). We update by replacing the * old

wrapping caused extraneous stars

> + * Do not allow backend_mem_allocated to go below zero. ereport if we
> + * would have. There's no need for a lock around the read here asit's

as it's

> + ereport(LOG, (errmsg("decrease reduces reported backend memory allocated below zero; setting reported to 0")));

errmsg() doesn't require the outside paranthesis since a couple years
ago.

> + /*
> + * Until header allocation is included in context->mem_allocated cast to
> + * slab and decrement the headerSize

add a comma before "cast" ?

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-08-31 17:06:32 Re: SQL/JSON features for v15
Previous Message Pavel Stehule 2022-08-31 16:59:23 Re: [PATCH] Query Jumbling for CALL and SET utility statements