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

From Mark Dilger
Subject Re: Should we add xid_current() or a int8->xid cast?
Date
Msg-id 2B1364F4-8522-4357-9051-19118B852DA4@enterprisedb.com
Whole thread Raw
In response to Re: Should we add xid_current() or a int8->xid cast?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Should we add xid_current() or a int8->xid cast?
List pgsql-hackers

> On Apr 4, 2020, at 7:11 AM, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Sat, Apr 4, 2020 at 4:45 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>> FYI, (not the responsibility of this patch), we never quite define what the abbreviation "xip" stands for.  If
"Activexid8s at the time of the snapshot." were rewritten as "In progress xid8s at the time of the snapshot", it might
beslightly easier for the reader to figure out that "xip" = "Xid8s In Progress".  As it stands, nothing in the docs
seemsto explain the abbrevation.  See doc/src/sgml/func.sgml 
>
> You're right.  Done.

Thanks!

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

The "xid8_" warts are partly motivated by having a type named "xid8", which is a bit of a wart in itself.

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

I like some aspects of this, but not others.  Function pg_stat_get_activity(), which gets exposed through view
pg_stat_activityexposes both "backend_xid" and "backend_xmin" as (32-bit) xid.  Your new function names are not
sufficientlydistinct from these older names for users to easily remember the difference: 

select pg_snapshot_xmax(st.snap)
    from snapshot_test st, pg_stat_activity sa
    where pg_snapshot_xmin(st.snap) = sa.backend_xmin;
ERROR:  operator does not exist: xid8 = xid

SELECT * FROM pg_stat_activity s WHERE backend_xid = pg_current_xact_id();
ERROR:  operator does not exist: xid = xid8

SELECT pg_xact_status(backend_xmin), * FROM pg_stat_activity;
ERROR:  function pg_xact_status(xid) does not exist

It's not the end of the world, and users can figure out to put a cast on those, but it's kind of ugly.

It was cleaner before v10, when "backend_xid = xid8_current()" clearly had a xid vs. xid8 mismatch. On the other hand,
ifthe xid columns in pg_stat_activity and elsewhere eventually get upgraded to xid8 fields, then the new naming
conventionin v10 will be cleaner. 

As such, I'm ±0 for the change.


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Alvaro Herrera
Date:
Subject: Re: range_agg