Add sub-transaction overflow status in pg_stat_activity

On Mon, Dec 6, 2021 at 8:17 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

If the subtransaction cache is overflowed in some of the transactions
then it will affect all the concurrent queries as they need to access
the SLRU for checking the visibility of each tuple. But currently
there is no way to identify whether in any backend subtransaction is
overflowed or what is the current active subtransaction count.
Attached patch adds subtransaction count and subtransaction overflow
status in pg_stat_activity. I have implemented this because of the
recent complain about the same[1]

[1]
/messages/by-id/CAFiTN-t5BkwdHm1bV8ez64guWZJB_Jjhb7arsQsftxEwpYwObg@mail.gmail.com

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Hi,

bq. there is a no way to

Extra 'a' before no.

+ * Number of active subtransaction in the current session.

subtransaction -> subtransactions

+ * Whether subxid count overflowed in the current session.

It seems 'count' can be dropped from the sentence.

Cheers

On Mon, Dec 6, 2021 at 8:16 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

If the subtransaction cache is overflowed in some of the transactions
then it will affect all the concurrent queries as they need to access
the SLRU for checking the visibility of each tuple. But currently
there is no way to identify whether in any backend subtransaction is
overflowed or what is the current active subtransaction count.

I think it's a good idea – had the same need when recently researching
various issues with subtransactions [1]https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful, needed to patch Postgres in
benchmarking environments. To be fair, there is a way to understand that
the overflowed state is reached for PG 13+ – on standbys, observe reads in
Subtrans in pg_stat_slru. But of course, it's an indirect way.

I see that the patch adds two new columns to pg_stat_activity:
subxact_count and subxact_overflowed. This should be helpful to have.
Additionally, exposing the lastOverflowedXid value would be also good for
troubleshooting of subtransaction edge and corner cases – a bug recently
fixed in all current versions [2]https://commitfest.postgresql.org/36/3399/ was really tricky to troubleshoot in
production because this value is not visible to DBAs.

[1]: https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful
https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful
[2]: https://commitfest.postgresql.org/36/3399/

+      <entry role="catalog_table_entry"><para role="column_definition">
+       <structfield>subxact_count</structfield> <type>xid</type>
+      </para>
+      <para>
+       The current backend's active subtransactions count.

subtransaction (no s)

+ Set to true if current backend's subtransaction cache is overflowed.

Say "has overflowed"

+		if (local_beentry->subxact_count > 0)
+		{
+			values[30] = local_beentry->subxact_count;
+			values[31] = local_beentry->subxact_overflowed;
+		}
+		else
+		{
+			nulls[30] = true;
+			nulls[31] = true;
+		}

Why is the subxact count set to NULL instead of zero ?

You added this to pg_stat_activity, which already has a lot of fields.
We talked a few months ago about not adding more fields that weren't commonly
used.
/messages/by-id/20210426191811.sp3o77doinphyjhu@alap3.anarazel.de

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a function like
pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;

--
Justin

On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

Thanks for the review I will work on these comments.

+      <entry role="catalog_table_entry"><para role="column_definition">
+       <structfield>subxact_count</structfield> <type>xid</type>
+      </para>
+      <para>
+       The current backend's active subtransactions count.

subtransaction (no s)

+ Set to true if current backend's subtransaction cache is overflowed.

Say "has overflowed"

+             if (local_beentry->subxact_count > 0)
+             {
+                     values[30] = local_beentry->subxact_count;
+                     values[31] = local_beentry->subxact_overflowed;
+             }
+             else
+             {
+                     nulls[30] = true;
+                     nulls[31] = true;
+             }

Why is the subxact count set to NULL instead of zero ?

You added this to pg_stat_activity, which already has a lot of fields.
We talked a few months ago about not adding more fields that weren't commonly
used.
/messages/by-id/20210426191811.sp3o77doinphyjhu@alap3.anarazel.de

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a function like
pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;

Yeah, this is a valid point, I will change this accordingly.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

On Tue, Dec 7, 2021 at 10:29 AM Nikolay Samokhvalov
<samokhvalov@gmail.com> wrote:

On Mon, Dec 6, 2021 at 8:16 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

If the subtransaction cache is overflowed in some of the transactions
then it will affect all the concurrent queries as they need to access
the SLRU for checking the visibility of each tuple. But currently
there is no way to identify whether in any backend subtransaction is
overflowed or what is the current active subtransaction count.

I think it's a good idea – had the same need when recently researching various issues with subtransactions [1], needed to patch Postgres in benchmarking environments. To be fair, there is a way to understand that the overflowed state is reached for PG 13+ – on standbys, observe reads in Subtrans in pg_stat_slru. But of course, it's an indirect way.

Yeah right.

I see that the patch adds two new columns to pg_stat_activity: subxact_count and subxact_overflowed. This should be helpful to have. Additionally, exposing the lastOverflowedXid value would be also good for troubleshooting of subtransaction edge and corner cases – a bug recently fixed in all current versions [2] was really tricky to troubleshoot in production because this value is not visible to DBAs.

Yeah, we can show this too, although we need to take ProcArrayLock in
the shared mode for reading this, but anyway that will be done on
users request so should not be an issue IMHO.

I will post the updated patch soon along with comments given by
Zhihong Yu and Justin.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

On 12/6/21, 8:19 PM, "Dilip Kumar" <dilipbalaut@gmail.com> wrote:

If the subtransaction cache is overflowed in some of the transactions
then it will affect all the concurrent queries as they need to access
the SLRU for checking the visibility of each tuple. But currently
there is no way to identify whether in any backend subtransaction is
overflowed or what is the current active subtransaction count.
Attached patch adds subtransaction count and subtransaction overflow
status in pg_stat_activity. I have implemented this because of the
recent complain about the same[1]

I'd like to give a general +1 to this effort. Thanks for doing this!
I've actually created a function to provide this information in the
past, so I will help review.

Nathan

I also want to +1 this this effort. Exposing subtransaction usage is very useful.

It would also be extremely beneficial to add both subtransaction usage and overflow counters to pg_stat_database.

Monitoring tools that capture deltas on pg_stat_database will be able to generate historical analysis and usage trends of subtransactions.

On 12/7/21, 5:34 PM, "Bossart, Nathan" <bossartn@amazon.com> wrote:

On 12/6/21, 8:19 PM, "Dilip Kumar" <dilipbalaut@gmail.com> wrote:

If the subtransaction cache is overflowed in some of the transactions
then it will affect all the concurrent queries as they need to access
the SLRU for checking the visibility of each tuple. But currently
there is no way to identify whether in any backend subtransaction is
overflowed or what is the current active subtransaction count.
Attached patch adds subtransaction count and subtransaction overflow
status in pg_stat_activity. I have implemented this because of the
recent complain about the same[1]

I'd like to give a general +1 to this effort. Thanks for doing this!
I've actually created a function to provide this information in the
past, so I will help review.

Nathan

On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

You added this to pg_stat_activity, which already has a lot of fields.
We talked a few months ago about not adding more fields that weren't commonly
used.
/messages/by-id/20210426191811.sp3o77doinphyjhu@alap3.anarazel.de

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a function like
pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;

I have provided two function, one for subtransaction counts and other
whether subtransaction cache is overflowed or not, we can use like
this, if we think this is better way to do it then we can also add
another function for the lastOverflowedXid

postgres[43994]=# select id, pg_stat_get_backend_pid(id) as pid,
pg_stat_get_backend_subxact_count(id) as nsubxact,
pg_stat_get_backend_subxact_overflow(id) as overflowed from
pg_stat_get_backend_idset() as id;
id | pid | nsubxact | overflowed
----+-------+----------+------------
1 | 43806 | 0 | f
2 | 43983 | 64 | t
3 | 43994 | 0 | f
4 | 44323 | 22 | f
5 | 43802 | 0 | f
6 | 43801 | 0 | f
7 | 43804 | 0 | f
(7 rows)

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

On 12/13/21, 6:30 AM, "Dilip Kumar" <dilipbalaut@gmail.com> wrote:

On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a function like
pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;

I have provided two function, one for subtransaction counts and other
whether subtransaction cache is overflowed or not, we can use like
this, if we think this is better way to do it then we can also add
another function for the lastOverflowedXid

The general approach looks good to me. I think we could have just one
function for all three values, though.

Nathan

Hi,

I have looked into the v2 patch and here are my comments:

+   PG_RETURN_INT32(local_beentry->subxact_overflowed);
+}

Should this be PG_RETURN_BOOL instead of PG_RETURN_INT32??

--

+{ oid => '6107', descr => 'statistics: cached subtransaction count of
backend',
+  proname => 'pg_stat_get_backend_subxact_count', provolatile => 's',
proparallel => 'r',
+  prorettype => 'int4', proargtypes => 'int4',
+  prosrc => 'pg_stat_get_backend_subxact_count' },
+{ oid => '6108', descr => 'statistics: subtransaction cache of backend
overflowed',
+  proname => 'pg_stat_get_backend_subxact_overflow', provolatile => 's',
proparallel => 'r',
+  prorettype => 'bool', proargtypes => 'int4',
+  prosrc => 'pg_stat_get_backend_subxact_overflow' },

The description says that the two new functions show the statistics for
"cached subtransaction count of backend" and "subtransaction cache of
backend overflowed". But, when these functions are called it shows these
stats for the non-backend processes like checkpointer, walwriter etc as
well. Should that happen?

--

typedef struct LocalPgBackendStatus
     * not.
     */
    TransactionId backend_xmin;
+
+   /*
+    * Number of cached subtransactions in the current session.
+    */
+   int subxact_count;
+
+   /*
+    * The number of subtransactions in the current session exceeded the
cached
+    * subtransaction limit.
+    */
+   bool subxact_overflowed;

All the variables inside this LocalPgBackendStatus structure are prefixed
with "backend" word. Can we do the same for the newly added variables as
well?

--

+ * Get the xid and xmin, nsubxid and overflow status of the backend.
The

Should this be put as - "xid, xmin, nsubxid and overflow" instead of "xid
and xmin, nsubxid and overflow"?

--
With Regards,
Ashutosh Sharma.

On Mon, Dec 13, 2021 at 7:58 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:

On Tue, Dec 14, 2021 at 3:57 AM Bossart, Nathan <bossartn@amazon.com> wrote:

On 12/13/21, 6:30 AM, "Dilip Kumar" <dilipbalaut@gmail.com> wrote:

On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a function like
pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;

I have provided two function, one for subtransaction counts and other
whether subtransaction cache is overflowed or not, we can use like
this, if we think this is better way to do it then we can also add
another function for the lastOverflowedXid

The general approach looks good to me. I think we could have just one
function for all three values, though.

If we create just one function then the output type will be a tuple
then we might have to add another view on top of that. Is there any
better way to do that?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

On Tue, Dec 14, 2021 at 6:23 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:

Hi,

I have looked into the v2 patch and here are my comments:

+   PG_RETURN_INT32(local_beentry->subxact_overflowed);
+}

Should this be PG_RETURN_BOOL instead of PG_RETURN_INT32??

--

+{ oid => '6107', descr => 'statistics: cached subtransaction count of backend',
+  proname => 'pg_stat_get_backend_subxact_count', provolatile => 's', proparallel => 'r',
+  prorettype => 'int4', proargtypes => 'int4',
+  prosrc => 'pg_stat_get_backend_subxact_count' },
+{ oid => '6108', descr => 'statistics: subtransaction cache of backend overflowed',
+  proname => 'pg_stat_get_backend_subxact_overflow', provolatile => 's', proparallel => 'r',
+  prorettype => 'bool', proargtypes => 'int4',
+  prosrc => 'pg_stat_get_backend_subxact_overflow' },

The description says that the two new functions show the statistics for "cached subtransaction count of backend" and "subtransaction cache of backend overflowed". But, when these functions are called it shows these stats for the non-backend processes like checkpointer, walwriter etc as well. Should that happen?

--

typedef struct LocalPgBackendStatus
* not.
*/
TransactionId backend_xmin;
+
+   /*
+    * Number of cached subtransactions in the current session.
+    */
+   int subxact_count;
+
+   /*
+    * The number of subtransactions in the current session exceeded the cached
+    * subtransaction limit.
+    */
+   bool subxact_overflowed;

All the variables inside this LocalPgBackendStatus structure are prefixed with "backend" word. Can we do the same for the newly added variables as well?

--

+ * Get the xid and xmin, nsubxid and overflow status of the backend. The

Should this be put as - "xid, xmin, nsubxid and overflow" instead of "xid and xmin, nsubxid and overflow"?

Thanks, Ashutosh, I will work on your comments and post an updated
version by next week.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

On Fri, Dec 17, 2021 at 09:00:04AM +0530, Dilip Kumar wrote:

On Tue, Dec 14, 2021 at 3:57 AM Bossart, Nathan <bossartn@amazon.com> wrote:

On 12/13/21, 6:30 AM, "Dilip Kumar" <dilipbalaut@gmail.com> wrote:

On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a function like
pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;

I have provided two function, one for subtransaction counts and other
whether subtransaction cache is overflowed or not, we can use like
this, if we think this is better way to do it then we can also add
another function for the lastOverflowedXid

The general approach looks good to me. I think we could have just one
function for all three values, though.

If we create just one function then the output type will be a tuple
then we might have to add another view on top of that. Is there any
better way to do that?

I don't think you'd need to add a view on top of it.

Compare:

postgres=# SELECT 1, pg_config() LIMIT 1;
?column? | pg_config
----------+----------------------------
1 | (BINDIR,/usr/pgsql-14/bin)

postgres=# SELECT 1, c FROM pg_config() c LIMIT 1;
?column? | c
----------+----------------------------
1 | (BINDIR,/usr/pgsql-14/bin)

postgres=# SELECT 1, c.* FROM pg_config() c LIMIT 1;
?column? | name | setting
----------+--------+-------------------
1 | BINDIR | /usr/pgsql-14/bin

On Fri, Dec 17, 2021 at 9:32 AM Justin Pryzby <pryzby@telsasoft.com> wrote:

On Fri, Dec 17, 2021 at 09:00:04AM +0530, Dilip Kumar wrote:

On Tue, Dec 14, 2021 at 3:57 AM Bossart, Nathan <bossartn@amazon.com>

wrote:

On 12/13/21, 6:30 AM, "Dilip Kumar" <dilipbalaut@gmail.com> wrote:

On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby <pryzby@telsasoft.com>

wrote:

Since I think this field is usually not interesting to most users of
pg_stat_activity, maybe this should instead be implemented as a

function like

pg_backend_get_subxact_status(pid).

People who want to could use it like:
SELECT * FROM pg_stat_activity psa,

pg_backend_get_subxact_status(pid) sub;

I have provided two function, one for subtransaction counts and other
whether subtransaction cache is overflowed or not, we can use like
this, if we think this is better way to do it then we can also add
another function for the lastOverflowedXid

The general approach looks good to me. I think we could have just one
function for all three values, though.

If we create just one function then the output type will be a tuple
then we might have to add another view on top of that. Is there any
better way to do that?

I don't think you'd need to add a view on top of it.

Compare:

postgres=# SELECT 1, pg_config() LIMIT 1;
?column? | pg_config
----------+----------------------------
1 | (BINDIR,/usr/pgsql-14/bin)

postgres=# SELECT 1, c FROM pg_config() c LIMIT 1;
?column? | c
----------+----------------------------
1 | (BINDIR,/usr/pgsql-14/bin)

postgres=# SELECT 1, c.* FROM pg_config() c LIMIT 1;
?column? | name | setting
----------+--------+-------------------
1 | BINDIR | /usr/pgsql-14/bin

Okay, that makes sense, I have modified it to make a single function.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

On Tue, Dec 14, 2021 at 6:23 PM Ashutosh Sharma <ashu.coek88@gmail.com>
wrote:

In the latest patch I have fixed comments given here except a few.

I have looked into the v2 patch and here are my comments:

+   PG_RETURN_INT32(local_beentry->subxact_overflowed);
+}

Should this be PG_RETURN_BOOL instead of PG_RETURN_INT32??

With the new patch this is not relevant because we are returning a tuple.

+{ oid => '6107', descr => 'statistics: cached subtransaction count of
backend',
+  proname => 'pg_stat_get_backend_subxact_count', provolatile => 's',
proparallel => 'r',
+  prorettype => 'int4', proargtypes => 'int4',
+  prosrc => 'pg_stat_get_backend_subxact_count' },
+{ oid => '6108', descr => 'statistics: subtransaction cache of backend
overflowed',
+  proname => 'pg_stat_get_backend_subxact_overflow', provolatile => 's',
proparallel => 'r',
+  prorettype => 'bool', proargtypes => 'int4',
+  prosrc => 'pg_stat_get_backend_subxact_overflow' },

The description says that the two new functions show the statistics for
"cached subtransaction count of backend" and "subtransaction cache of
backend overflowed". But, when these functions are called it shows these
stats for the non-backend processes like checkpointer, walwriter etc as
well. Should that happen?

I am following similar description as pg_stat_get_backend_pid,
pg_stat_get_backend_idset and other relevant functioins.

typedef struct LocalPgBackendStatus
     * not.
     */
    TransactionId backend_xmin;
+
+   /*
+    * Number of cached subtransactions in the current session.
+    */
+   int subxact_count;
+
+   /*
+    * The number of subtransactions in the current session exceeded the
cached
+    * subtransaction limit.
+    */
+   bool subxact_overflowed;

All the variables inside this LocalPgBackendStatus structure are prefixed
with "backend" word. Can we do the same for the newly added variables as
well?

Done

+ * Get the xid and xmin, nsubxid and overflow status of the backend.
The

Should this be put as - "xid, xmin, nsubxid and overflow" instead of "xid
and xmin, nsubxid and overflow"?

I missed to fix this one in the last patch so updated again.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Thanks for the new patch!

+       <para>
+        Returns a record of information about the backend's subtransactions.
+        The fields returned are <parameter>subxact_count</parameter> identifies
+        number of active subtransaction and <parameter>subxact_overflow
+        </parameter> shows whether the backend's subtransaction cache is
+        overflowed or not.
+       </para></entry>
+       </para></entry>

nitpick: There is an extra "</para></entry>" here.

Would it be more accurate to say that subxact_count is the number of
subxids that are cached? It can only ever go up to
PGPROC_MAX_CACHED_SUBXIDS.

Nathan

On Thu, Jan 13, 2022 at 10:27:31PM +0000, Bossart, Nathan wrote:

Thanks for the new patch!

+       <para>
+        Returns a record of information about the backend's subtransactions.
+        The fields returned are <parameter>subxact_count</parameter> identifies
+        number of active subtransaction and <parameter>subxact_overflow
+        </parameter> shows whether the backend's subtransaction cache is
+        overflowed or not.
+       </para></entry>
+       </para></entry>

nitpick: There is an extra "</para></entry>" here.

Also the sentence looks a bit weird. I think something like that would be
better:

+        Returns a record of information about the backend's subtransactions.
+        The fields returned are <parameter>subxact_count</parameter>, which
+        identifies the number of active subtransaction and <parameter>subxact_overflow
+        </parameter>, which shows whether the backend's subtransaction cache is
+        overflowed or not.

While on the sub-transaction overflow topic, I'm wondering if we should also
raise a warning (maybe optionally) immediately when a backend overflows (so in
GetNewTransactionId()).

Like many I previously had to investigate a slowdown due to sub-transaction
overflow, and even with the information available in a monitoring view (I had
to rely on a quick hackish extension as I couldn't patch postgres) it's not
terribly fun to do this way. On top of that log analyzers like pgBadger could
help to highlight such a problem.

I don't want to derail this thread so let me know if I should start a distinct
discussion for that.

On Fri, Jan 14, 2022 at 1:17 PM Julien Rouhaud <rjuju123@gmail.com> wrote:

On Thu, Jan 13, 2022 at 10:27:31PM +0000, Bossart, Nathan wrote:

Thanks for the new patch!

+       <para>
+        Returns a record of information about the backend's

subtransactions.

+ The fields returned are <parameter>subxact_count</parameter>

identifies

+        number of active subtransaction and <parameter>subxact_overflow
+        </parameter> shows whether the backend's subtransaction cache is
+        overflowed or not.
+       </para></entry>
+       </para></entry>

nitpick: There is an extra "</para></entry>" here.

Also the sentence looks a bit weird. I think something like that would be
better:

+ Returns a record of information about the backend's

subtransactions.

+ The fields returned are <parameter>subxact_count</parameter>,

which

+ identifies the number of active subtransaction and

<parameter>subxact_overflow

+ </parameter>, which shows whether the backend's subtransaction

cache is

+ overflowed or not.

Thanks for looking into this, I will work on this next week.

While on the sub-transaction overflow topic, I'm wondering if we should
also
raise a warning (maybe optionally) immediately when a backend overflows
(so in
GetNewTransactionId()).

Like many I previously had to investigate a slowdown due to sub-transaction
overflow, and even with the information available in a monitoring view (I
had
to rely on a quick hackish extension as I couldn't patch postgres) it's not
terribly fun to do this way. On top of that log analyzers like pgBadger
could
help to highlight such a problem.

I don't want to derail this thread so let me know if I should start a
distinct
discussion for that.

Yeah that seems like a good idea.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Julien Rouhaud <rjuju123@gmail.com> writes:

Like many I previously had to investigate a slowdown due to sub-transaction
overflow, and even with the information available in a monitoring view (I had
to rely on a quick hackish extension as I couldn't patch postgres) it's not
terribly fun to do this way. On top of that log analyzers like pgBadger could
help to highlight such a problem.

It feels to me like far too much effort is being invested in fundamentally
the wrong direction here. If the subxact overflow business is causing
real-world performance problems, let's find a way to fix that, not put
effort into monitoring tools that do little to actually alleviate anyone's
pain.

regards, tom lane