Re: A patch for get origin from commit_ts.
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "movead.li@highgo.ca" <movead.li@highgo.ca>
Cc: petr <petr@2ndquadrant.com>, simon <simon@2ndquadrant.com>, "Madan Kumar" <madankumar1993@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, craig <craig@2ndquadrant.com>, "Alvaro Herrera" <alvherre@2ndquadrant.com>, andres <andres@anarazel.de>, soumyadeep2007 <soumyadeep2007@gmail.com>
Date: 2020-07-06T08:01:36Z
Lists: pgsql-hackers
On Mon, Jul 06, 2020 at 11:12:30AM +0800, movead.li@highgo.ca wrote:
> Thanks for the points and follow them, new patch attached.
That was fast, thanks. I have not tested the patch, but there are
two things I missed a couple of hours back. Why do you need
pg_last_committed_xact_with_origin() to begin with? Wouldn't it be
more simple to just add a new column to pg_last_committed_xact() for
the replication origin? Contrary to pg_xact_commit_timestamp() that
should not be broken for compatibility reasons because it returns only
one value, we don't have this problem with pg_last_committed_xact() as
it already returns one tuple with two values.
+{ oid => '4179', descr => 'get commit origin of a transaction',
A second thing is that the OID of the new function should be in the
range 8000..9999, as per the policy introduced in commit a6417078.
src/include/catalog/unused_oids can be used to pick up a value.
--
Michael
Commits
-
Include replication origins in SQL functions for commit timestamp
- b1e48bbe64a4 14.0 landed
-
Create a script that can renumber manually-assigned OIDs.
- a6417078c414 12.0 cited