Horton

Re: A patch for get origin from commit_ts.

Simon Riggs <simon@2ndquadrant.com>

View thread View on postgr.es
From: Simon Riggs <simon@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Madan Kumar <madankumar1993@gmail.com>, "movead.li@highgo.ca" <movead.li@highgo.ca>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, Craig Ringer <craig@2ndquadrant.com>, Petr Jelinek <petr@2ndquadrant.com>, Álvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, soumyadeep2007@gmail.com
Date: 2020-07-02T07:52:45Z
Lists: pgsql-hackers 
On Thu, 2 Jul 2020 at 02:58, <michael@paquier.xyz> wrote:

> On Tue, Jun 30, 2020 at 01:58:17PM +0100, Simon Riggs wrote:
> > On Tue, 30 Jun 2020 at 02:17, Madan Kumar <madankumar1993@gmail.com>
> wrote:
> >> It may be better to have one single function returning both
> >> timestamp and origin for a given transaction ID.
> >
> > No need to change existing APIs.
>
> Adding a new function able to return both fields at the same time does
> not imply that we'd remove the original one, it just implies that we
> would be able to retrieve both fields with a single call of
> TransactionIdGetCommitTsData(), saving from an extra CommitTsSLRULock
> taken, etc.  That's actually what pglogical does with
> its pglogical_xact_commit_timestamp_origin() in
> pglogical_functions.c.  So adding one function able to return one
> tuple with the two fields, without removing the existing
> pg_xact_commit_timestamp() makes the most sense, no?
>

OK

-- 
Simon Riggs                http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases

Commits

  1. Include replication origins in SQL functions for commit timestamp

  2. Create a script that can renumber manually-assigned OIDs.