On 17 December 2016 at 00:13, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Dec 15, 2016 at 3:02 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:
>> I really wish we could just change the pg_stat_activity and
>> pg_stat_replication xid fields to be epoch qualified in a 64-bit wide
>> 'fullxid' type, or similar.
>
> I think that approach is worth considering.
I'm worried about how many monitoring tools it'd break.
Arguably most or all will already be broken and not know it, though.
Those that aren't will be using age(xid), which we can support just
fine for the new type too, so they won't notice.
Ideally I'd just like to widen 'xid' to 64-bits. This would upset
clients that use binary mode and "know" it's a 32-bit type on the
wire, though, so I'm not sure it's a good idea even though it'd be
nicer in pretty much every other way.
So the idea then is to add a new bigxid type, a 64-bit wide
epoch-extended xid, and replace _all_ appearances of 'xid' with it in
catalogs, views, etc, such that 'xid' is entirely deprecated.
Rather than convert 64-bit extended XIDs to 32-bit for internal
comparisons/functions/operators we'll just epoch-extend our 32-bit
xids, getting rid of the need to handle any sort of "too old" concept
in most cases.
The return type of txid_current() should probably change to the new
bitxid type. This'll upset apps that expect to do maths on it since
the new bigxid type won't have many operators, but since most (all?)
of that maths will be wrong I don't think that's a bad thing. Banging
in a ::bigint will quickfix so adaptation is easy, and it'll highlight
incorrect uses (many) of the call. The type is on-wire compatible with
the current bigint return type until you hit epoch 2^31 in which case
you have bigger things to worry about, like pending epoch wraparound.
HOWEVER, if we're going to really remove 'xid' from user view, it
should vanish from pg_database and pg_class too. That's a LOT more
intrusive, and widens pg_class by 4 bytes per row for minimal gain. No
entry there can ever have an epoch older than the current epoch - 1,
and only then the part that's after the wraparound threshold. pg_class
is a raw relation so we can't transform what the user sees via a view
or function.
Tools look at pg_class.relfrozenxid and pg_databse.datfrozenxid more
than probably anything else, so making changes that ignores them is
pretty pointless.
Everything else looks easy and minimally intrusive, but I'm not sure
there's a sensible answer to pg_class.relfrozenxid.
test=> select table_name, column_name from information_schema.columns
where data_type = 'xid';
table_name | column_name
----------------------+---------------
pg_class | relfrozenxid
pg_class | relminmxid
pg_database | datfrozenxid
pg_database | datminmxid
pg_locks | transactionid
pg_prepared_xacts | transaction
pg_stat_activity | backend_xid
pg_stat_activity | backend_xmin
pg_stat_replication | backend_xmin
pg_replication_slots | xmin
pg_replication_slots | catalog_xmin
(11 rows)
test=> SELECT proname FROM pg_proc WHERE prorettype = 'xid'::regtype
OR 'xid'::regtype = ANY (proargtypes);
proname
--------------------------
xidin
xidout
xideq
age
mxid_age
xideqint4
pg_get_multixact_members
pg_xact_commit_timestamp
xidrecv
xidsend
(10 rows)
test=> SELECT oprname FROM pg_operator WHERE 'xid'::regtype IN
(oprleft, oprright, oprresult);
oprname
---------
=
=
(2 rows)
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
