| 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
| 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. |