mxid_age() and age(xid) appear undocumented
I see d692308cf494f6126 mentions mxid_age() in passing, but there
appears to be no formal definition of either of these functions.
Should there be?
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Sun, Jul 1, 2018 at 11:18 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
I see d692308cf494f6126 mentions mxid_age() in passing, but there
appears to be no formal definition of either of these functions.Should there be?
It seems like a good idea to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Jul 5, 2018 at 12:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Jul 1, 2018 at 11:18 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:I see d692308cf494f6126 mentions mxid_age() in passing, but there
appears to be no formal definition of either of these functions.Should there be?
It seems like a good idea to me.
+1
--
Peter Geoghegan
On Thu, Jul 5, 2018 at 01:30:22PM -0700, Peter Geoghegan wrote:
On Thu, Jul 5, 2018 at 12:36 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Jul 1, 2018 at 11:18 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:I see d692308cf494f6126 mentions mxid_age() in passing, but there
appears to be no formal definition of either of these functions.Should there be?
It seems like a good idea to me.
+1
I looked into this and all the 4-byte xid functions are marked as
deprecated for the 8-byte variants. I don't think documenting 4-byte
mxid_age() and age(xid) makes sense anymore, and I don't see their value
enough to create 8-byte versions, so I just added C comments that they
were undocumented, in the attached patch.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
age.difftext/x-diff; charset=us-asciiDownload
diff --git a/src/backend/utils/adt/xid.c b/src/backend/utils/adt/xid.c
index 8ac1679c38..d2c637195c 100644
--- a/src/backend/utils/adt/xid.c
+++ b/src/backend/utils/adt/xid.c
@@ -98,6 +98,7 @@ xidneq(PG_FUNCTION_ARGS)
/*
* xid_age - compute age of an XID (relative to latest stable xid)
+ * This supports only 4-byte XIDs and is undocumented.
*/
Datum
xid_age(PG_FUNCTION_ARGS)
@@ -114,6 +115,7 @@ xid_age(PG_FUNCTION_ARGS)
/*
* mxid_age - compute age of a multi XID (relative to latest stable mxid)
+ * This supports only 4-byte XIDs and is undocumented.
*/
Datum
mxid_age(PG_FUNCTION_ARGS)
On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian <bruce@momjian.us> wrote:
I looked into this and all the 4-byte xid functions are marked as
deprecated for the 8-byte variants. I don't think documenting 4-byte
mxid_age() and age(xid) makes sense anymore, and I don't see their value
enough to create 8-byte versions, so I just added C comments that they
were undocumented, in the attached patch.
I'm sympathetic to the goal of making 4 byte XIDs an on-disk
implementation detail that is all but completely hidden from users.
However, there are practical problems with taking that to its logical
extreme. At least right now.
These functions are in fact documented -- albeit only partially. There
are references to both in "Routine Vacuuming". Moreover, those
references are rather useful; they're the basis of many
monitoring/alerting queries. If anything, I'd recommend adding more
documentation for these two functions.
We also continue to show 32-bit XIDs (alongside 32-bit relfrozenxid)
in the output of VACUUM VERBOSE/autovacuum log messages. (Though that
issue can be fixed fairly easily.)
The bottom line is that there is only one way to figure out the age of
a table right now, and it involves 32-bit XIDs/MXIDs, and these two
functions. And, if we were to change something in this area, we'd
definitely need to provide for the needs of those monitoring queries I
mentioned.
--
Peter Geoghegan
On Mon, Nov 13, 2023 at 5:01 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian <bruce@momjian.us> wrote:
I looked into this and all the 4-byte xid functions are marked as
deprecated for the 8-byte variants. I don't think documenting 4-byte
mxid_age() and age(xid) makes sense anymore, and I don't see their value
enough to create 8-byte versions, so I just added C comments that they
were undocumented, in the attached patch.I'm sympathetic to the goal of making 4 byte XIDs an on-disk
implementation detail that is all but completely hidden from users.
However, there are practical problems with taking that to its logical
extreme. At least right now.These functions are in fact documented -- albeit only partially. There
are references to both in "Routine Vacuuming". Moreover, those
references are rather useful; they're the basis of many
monitoring/alerting queries. If anything, I'd recommend adding more
documentation for these two functions.We also continue to show 32-bit XIDs (alongside 32-bit relfrozenxid)
in the output of VACUUM VERBOSE/autovacuum log messages. (Though that
issue can be fixed fairly easily.)The bottom line is that there is only one way to figure out the age of
a table right now, and it involves 32-bit XIDs/MXIDs, and these two
functions. And, if we were to change something in this area, we'd
definitely need to provide for the needs of those monitoring queries I
mentioned.
Also, the doc page [1]https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND mentions mxid_age(), but doesn't provide a
snippet to use it. The regular XID wraparound section above has such a
snippet. As a consequence, almost nobody monitors for MultiXact
wraparound – I noticed it recently once again, exploring numerous blog
posts and tools on this topic to write a howto [2]https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/-/blob/main/0044_how_to_monitor_transaction_id_wraparound_risks.md in my collection.
In other words, maybe there should be not only a reference doc for the
function itself present in the doc (the lack of it seems to be an
issue for all older versions), but also a snippet to control MultiXact
ID wraparound – while it's still a potential problem, it would be good
to have both a function reference doc and a how-to-use-it doc.
[1]: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND
[2]: https://gitlab.com/postgres-ai/postgresql-consulting/postgres-howtos/-/blob/main/0044_how_to_monitor_transaction_id_wraparound_risks.md
Hi,
On 2023-11-13 17:00:43 -0800, Peter Geoghegan wrote:
On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian <bruce@momjian.us> wrote:
I looked into this and all the 4-byte xid functions are marked as
deprecated for the 8-byte variants. I don't think documenting 4-byte
mxid_age() and age(xid) makes sense anymore, and I don't see their value
enough to create 8-byte versions, so I just added C comments that they
were undocumented, in the attached patch.I'm sympathetic to the goal of making 4 byte XIDs an on-disk
implementation detail that is all but completely hidden from users.
However, there are practical problems with taking that to its logical
extreme. At least right now.These functions are in fact documented -- albeit only partially. There
are references to both in "Routine Vacuuming". Moreover, those
references are rather useful; they're the basis of many
monitoring/alerting queries. If anything, I'd recommend adding more
documentation for these two functions.
+1
We also continue to show 32-bit XIDs (alongside 32-bit relfrozenxid)
in the output of VACUUM VERBOSE/autovacuum log messages. (Though that
issue can be fixed fairly easily.)
I'm not sure it should be fixed, as long as we track horizons (in memory and
relfrozenxid) etc in 32 bit. That seems like it'd just make it harder to
understand things.
The bottom line is that there is only one way to figure out the age of
a table right now, and it involves 32-bit XIDs/MXIDs, and these two
functions.
Yes. I'm -many on deprecating these functions, until we've actually improved
the situation.
And, if we were to change something in this area, we'd
definitely need to provide for the needs of those monitoring queries I
mentioned.
I think it'd be a bad idea to "deprecate" existing working queries, with the
replacement being a more complicated way to represent the same information.
Greetings,
Andres Freund
On Mon, Nov 13, 2023 at 05:32:24PM -0800, Andres Freund wrote:
Hi,
On 2023-11-13 17:00:43 -0800, Peter Geoghegan wrote:
On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian <bruce@momjian.us> wrote:
I looked into this and all the 4-byte xid functions are marked as
deprecated for the 8-byte variants. I don't think documenting 4-byte
mxid_age() and age(xid) makes sense anymore, and I don't see their value
enough to create 8-byte versions, so I just added C comments that they
were undocumented, in the attached patch.I'm sympathetic to the goal of making 4 byte XIDs an on-disk
implementation detail that is all but completely hidden from users.
However, there are practical problems with taking that to its logical
extreme. At least right now.These functions are in fact documented -- albeit only partially. There
are references to both in "Routine Vacuuming". Moreover, those
references are rather useful; they're the basis of many
monitoring/alerting queries. If anything, I'd recommend adding more
documentation for these two functions.+1
Seems people still like these functions, so here is a patch to properly
document them. :-)
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
Attachments:
age.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 93f068edcf..71713f471d 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25860,6 +25860,34 @@ SELECT collation for ('foo' COLLATE "de_DE");
</thead>
<tbody>
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>age</primary>
+ </indexterm>
+ <function>age</function> ( <type>xid</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of transactions between the supplied
+ transaction id and the current transaction counter.
+ </para></entry>
+ </row>
+
+ <row>
+ <entry role="func_table_entry"><para role="func_signature">
+ <indexterm>
+ <primary>mxid_age</primary>
+ </indexterm>
+ <function>mxid_age</function> ( <type>xid</type> )
+ <returnvalue>integer</returnvalue>
+ </para>
+ <para>
+ Returns the number of multixacts IDs between the supplied
+ multixact ID and the current multixacts counter.
+ </para></entry>
+ </row>
+
<row>
<entry role="func_table_entry"><para role="func_signature">
<indexterm>
On Fri, Nov 17, 2023 at 01:39:46PM -0500, Bruce Momjian wrote:
On Mon, Nov 13, 2023 at 05:32:24PM -0800, Andres Freund wrote:
Hi,
On 2023-11-13 17:00:43 -0800, Peter Geoghegan wrote:
On Mon, Nov 13, 2023 at 4:43 PM Bruce Momjian <bruce@momjian.us> wrote:
I looked into this and all the 4-byte xid functions are marked as
deprecated for the 8-byte variants. I don't think documenting 4-byte
mxid_age() and age(xid) makes sense anymore, and I don't see their value
enough to create 8-byte versions, so I just added C comments that they
were undocumented, in the attached patch.I'm sympathetic to the goal of making 4 byte XIDs an on-disk
implementation detail that is all but completely hidden from users.
However, there are practical problems with taking that to its logical
extreme. At least right now.These functions are in fact documented -- albeit only partially. There
are references to both in "Routine Vacuuming". Moreover, those
references are rather useful; they're the basis of many
monitoring/alerting queries. If anything, I'd recommend adding more
documentation for these two functions.+1
Seems people still like these functions, so here is a patch to properly
document them. :-)
Patch applied back to PG 16.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.