Thread: 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(-)
Re: pgsql: Include replication origins in SQL functions for commit timestam
From
Michael Paquier
Date:
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
Attachment
Re: pgsql: Include replication origins in SQL functions for commit timestam
From
Michael Paquier
Date:
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