Horton

Re: A patch for get origin from commit_ts.

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Petr Jelinek <petr@2ndquadrant.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, 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-03T05:10:59Z
Lists: pgsql-hackers 
On Thu, Jul 02, 2020 at 10:12:02AM +0200, Petr Jelinek wrote:
> On 02/07/2020 03:58, michael@paquier.xyz wrote:
>> 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.

Thanks.  Movead, please note that the patch is waiting on author?
Could you send an update if you think that those changes make sense?
--
Michael

Commits

  1. Include replication origins in SQL functions for commit timestamp

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