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
-
Include replication origins in SQL functions for commit timestamp
- b1e48bbe64a4 14.0 landed
-
Create a script that can renumber manually-assigned OIDs.
- a6417078c414 12.0 cited