Horton

Thread

Commits

  1. doc: Fix section of functions age(xid) and mxid_age(xid)

  1. mxid_age() and age(xid) appear undocumented

    David Rowley <david.rowley@2ndquadrant.com> — 2018-07-02T03:18:32Z

    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

  2. Re: mxid_age() and age(xid) appear undocumented

    Robert Haas <robertmhaas@gmail.com> — 2018-07-05T19:36:19Z

    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

  3. Re: mxid_age() and age(xid) appear undocumented

    Peter Geoghegan <pg@bowt.ie> — 2018-07-05T20:30:22Z

    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

  4. Re: mxid_age() and age(xid) appear undocumented

    Bruce Momjian <bruce@momjian.us> — 2023-11-14T00:43:18Z

    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.

  5. Re: mxid_age() and age(xid) appear undocumented

    Peter Geoghegan <pg@bowt.ie> — 2023-11-14T01:00:43Z

    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

  6. Re: mxid_age() and age(xid) appear undocumented

    Nikolay Samokhvalov <samokhvalov@gmail.com> — 2023-11-14T01:05:27Z

    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] 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] 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

  7. Re: mxid_age() and age(xid) appear undocumented

    Andres Freund <andres@anarazel.de> — 2023-11-14T01:32:24Z

    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

  8. Re: mxid_age() and age(xid) appear undocumented

    Bruce Momjian <bruce@momjian.us> — 2023-11-17T18:39:46Z

    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.

  9. Re: mxid_age() and age(xid) appear undocumented

    Bruce Momjian <bruce@momjian.us> — 2023-11-24T19:36:16Z

    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.