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
