Обсуждение: pgsql: Include replication origins in SQL functions for commit timestam

Include replication origins in SQL functions for commit timestamp

This includes two changes:
- Addition of a new function pg_xact_commit_timestamp_origin() able, for
a given transaction ID, to return the commit timestamp and replication
origin of this transaction.  An equivalent function existed in
pglogical.
- Addition of the replication origin to pg_last_committed_xact().

The commit timestamp manager includes already APIs able to return the
replication origin of a transaction on top of its commit timestamp, but
the code paths for replication origins were never stressed as those
functions have never looked for a replication origin, and the SQL
functions available have never included this information since their
introduction in 73c986a.

While on it, refactor a test of modules/commit_ts/ to use tstzrange() to
check that a transaction timestamp is within the wanted range, making
the test a bit easier to read.

Bump catalog version.

Author: Movead Li
Reviewed-by: Madan Kumar, Michael Paquier
Discussion: https://postgr.es/m/2020051116430836450630@highgo.ca

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/b1e48bbe64a411666bb1928b9741e112e267836d

Modified Files
--------------
doc/src/sgml/func.sgml                             | 22 ++++-
src/backend/access/transam/commit_ts.c             | 71 +++++++++++++++--
src/include/catalog/catversion.h                   |  2 +-
src/include/catalog/pg_proc.dat                    | 15 +++-
.../commit_ts/expected/commit_timestamp.out        | 93 +++++++++++++++++++++-
.../commit_ts/expected/commit_timestamp_1.out      | 75 ++++++++++++++++-
.../modules/commit_ts/sql/commit_timestamp.sql     | 35 +++++++-
7 files changed, 295 insertions(+), 18 deletions(-)

On Sun, Jul 12, 2020 at 11:47:38AM +0000, Michael Paquier wrote:
> Include replication origins in SQL functions for commit timestamp
>
> While on it, refactor a test of modules/commit_ts/ to use tstzrange() to
> check that a transaction timestamp is within the wanted range, making
> the test a bit easier to read.

longfin has been failing here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2020-07-12%2011%3A49%3A08

The buildfarm logs include no output, but the problem comes from
-DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, where replication origins
should be prefixed by "regress_".  I did not know that this rule was
applied here.
--
Michael

On Sun, Jul 12, 2020 at 09:25:07PM +0900, Michael Paquier wrote:
> longfin has been failing here:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2020-07-12%2011%3A49%3A08
>
> The buildfarm logs include no output, but the problem comes from
> -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS, where replication origins
> should be prefixed by "regress_".  I did not know that this rule was
> applied here.

Sorry for the delay.  jacana has been complaining here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2020-07-12%2018%3A02%3A48

Visily switching to tstzrange() is not a brilliant idea, as I suspect
here that the problem is caused by the timestamp comparison in the
upper bound: using the internal range checks, the upper bound is
excluded, so if the follow-up query's now() matches the commit
timestamp of the previous transaction, the comparison fails.
--
Michael