Re: A patch for get origin from commit_ts.

From: michael(at)paquier(dot)xyz
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Madan Kumar <madankumar1993(at)gmail(dot)com>, "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, soumyadeep2007(at)gmail(dot)com
Subject: Re: A patch for get origin from commit_ts.
Date: 2020-07-02 01:58:52
Message-ID: 20200702015852.GE10408@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 30, 2020 at 01:58:17PM +0100, Simon Riggs wrote:
> On Tue, 30 Jun 2020 at 02:17, Madan Kumar <madankumar1993(at)gmail(dot)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?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-07-02 02:14:48 Re: Asynchronous Append on postgres_fdw nodes.
Previous Message michael 2020-07-02 01:50:46 Re: A patch for get origin from commit_ts.