Re: A patch for get origin from commit_ts.

Petr Jelinek <petr@2ndquadrant.com>

From: Petr Jelinek <petr@2ndquadrant.com>
To: michael@paquier.xyz, Simon Riggs <simon@2ndquadrant.com>
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>, Álvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, soumyadeep2007@gmail.com
Date: 2020-07-02T08:12:02Z
Lists: pgsql-hackers
On 02/07/2020 03: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?


Agreed, sounds reasonable.

I also (I suspect like Álvaro) parsed your original message as wanting 
to remove origin from the record completely.

-- 
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/



Commits

  1. Include replication origins in SQL functions for commit timestamp

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