Re: Should we add xid_current() or a int8->xid cast?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Mark Dilger <hornschnorter(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Should we add xid_current() or a int8->xid cast?
Date: 2020-04-04 14:11:06
Message-ID: CA+hUKGLGh0xZroJ4zwiGPpJ3yJBzd93SM8vuUpd9m7vGT8kuUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 4, 2020 at 4:45 AM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> FYI, (not the responsibility of this patch), we never quite define what the abbreviation "xip" stands for. If "Active xid8s at the time of the snapshot." were rewritten as "In progress xid8s at the time of the snapshot", it might be slightly easier for the reader to figure out that "xip" = "Xid8s In Progress". As it stands, nothing in the docs seems to explain the abbrevation. See doc/src/sgml/func.sgml

You're right. Done.

I also noticed that "xid8s" didn't flow very well here, so I changed
it to "transaction IDs" in a couple of places like that (which I think
is fine in these English sentences, to mean xid, xid8 or bigint
depending on the context).

I also removed a sentence about values being "extended with an epoch",
because that's not really how we want people to think about this stuff
anymore. It's rather the other way around: transaction IDs begin life
as 64 bit numbers and then get sliced.

I noticed that the description of xmax was flat out wrong (it didn't
know about ancient commit 6bd4f401), so I rewrote it. And then while
exercising my backspace key, it bothered me that the description of
xip_list said almost the same thing twice so I kept only the more
accurate of two sentences.

However, I am getting cold feet about the new function names. The
existing naming structure made sense when all this stuff originated in
a contrib module with "txid_" as a prefix all over the place, but now
that 64 bit IDs are a core concept, I wonder if we shouldn't aim for
something that looks a little more like core functionality and doesn't
have those "xid8_" warts in the names. Here's what I now propose:

Transaction ID functions, using names that fit with others (cf
pg_xact_commit_timestamp()):

pg_current_xact_id()
pg_current_xact_id_if_assigned()
pg_xact_status(xid8)

Snapshot functions (cf pg_export_snapshot()):

pg_current_snapshot()
pg_snapshot_xmin(pg_snapshot)
pg_snapshot_xmax(pg_snapshot)
pg_snapshot_xip(pg_snapshot)
pg_visible_in_snapshot(xid8, pg_snapshot)

Here's a patch set like that (0003 has been squashed into 0002).

Attachment Content-Type Size
v10-0001-Add-SQL-type-xid8-to-expose-FullTransactionId-to.patch text/x-patch 26.6 KB
v10-0002-Introduce-xid8-based-functions-to-replace-txid_X.patch text/x-patch 83.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2020-04-04 14:43:44 Re: adding partitioned tables to publications
Previous Message Robert Haas 2020-04-04 13:36:08 Re: backup manifests and contemporaneous buildfarm failures