Horton

Thread

Commits

  1. Include replication origins in SQL functions for commit timestamp

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

  1. A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-05-11T08:43:11Z

    Hello hackers,

I am researching about 'origin' in PostgreSQL, mainly it used in logical
decoding to filter transaction from non-local source. I notice that the
'origin' is stored in commit_ts so that I think we are possible to get 'origin'
of a transaction from commit_ts.

But I can not fond any code to get 'origin' from commit_ts, just like it is
producing data which nobody cares about. Can I know what's the purpose
of the 'origin' in commit_ts? Do you think we should add some support
to the careless data?

For example, I add a function to get 'origin' from commit_ts:
=======================================
postgres=# select pg_xact_commit_origin('490');
 pg_xact_commit_origin 
-----------------------
 test_origin
(1 row)

postgres=# select pg_xact_commit_origin('491');
 pg_xact_commit_origin 
-----------------------
 test_origin1
(1 row)

postgres=#
=======================================




Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  2. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-05-12T01:45:37Z

    On Mon, May 11, 2020 at 04:43:11PM +0800, movead.li@highgo.ca wrote:
> But I can not fond any code to get 'origin' from commit_ts, just like it is
> producing data which nobody cares about. Can I know what's the purpose
> of the 'origin' in commit_ts? Do you think we should add some support
> to the careless data?

I have not thought about this matter, but it seems to me that you
should add this patch to the upcoming commit fest for evaluation:
https://commitfest.postgresql.org/28/

This is going to take a couple of months though as the main focus
lately is the stability of 13.
--
Michael

  3. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-05-13T08:29:19Z

    >I have not thought about this matter, but it seems to me that you
>should add this patch to the upcoming commit fest for evaluation:
>https://commitfest.postgresql.org/28/ 
Thanks.

I think about it more detailed, and find it's better to show the 'roident'
other than 'roname'. Because an old 'roident' value will be used
immediately after dropped, and a new patch attached with test case
and documentation.

============================================
SELECT pg_xact_commit_origin('490');
 pg_xact_commit_origin 
-----------------------
                     1
(1 row)

SELECT pg_xact_commit_origin('491');
 pg_xact_commit_origin 
-----------------------
                     2
(1 row)
============================================




Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  4. Re: A patch for get origin from commit_ts.

    Madan Kumar <madankumar1993@gmail.com> — 2020-06-30T01:17:27Z

    Hello hackers,

We already have pg_xact_commit_timestamp() that returns the timestamp of
the commit. It may be better to have one single function returning both
timestamp and origin for a given transaction ID.

A second thing is that TransactionIdGetCommitTsData() was introdued in
core(73c986add). It has only one caller pg_xact_commit_timestamp() which
passes RepOriginId as NULL, making last argument to the
TransactionIdGetCommitTsData() a dead code in core.

Quick code search shows that it is getting used by pglogical (caller:
https://sources.debian.org/src/pglogical/2.3.2-1/pglogical_conflict.c/?hl=509#L509).
CCing Craig Ringer and Petr Jelinek for the inputs.

Warm Regards,
Madan Kumar K
"There is no Elevator to Success. You have to take the Stairs"

  5. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-06-30T04:41:14Z

    On Mon, Jun 29, 2020 at 06:17:27PM -0700, Madan Kumar wrote:
> We already have pg_xact_commit_timestamp() that returns the timestamp of
> the commit. It may be better to have one single function returning both
> timestamp and origin for a given transaction ID.
> 
> A second thing is that TransactionIdGetCommitTsData() was introdued in
> core(73c986add). It has only one caller pg_xact_commit_timestamp() which
> passes RepOriginId as NULL, making last argument to the
> TransactionIdGetCommitTsData() a dead code in core.
> 
> Quick code search shows that it is getting used by pglogical (caller:
> https://sources.debian.org/src/pglogical/2.3.2-1/pglogical_conflict.c/?hl=509#L509).
> CCing Craig Ringer and Petr Jelinek for the inputs.

Another question that has popped up when doing this review is what
would be the use-case of adding this information at SQL level knowing
that logical replication exists since 10?  Having dead code in the
backend tree is not a good idea of course, so we can also have as
argument to simplify TransactionIdGetCommitTsData().  Now, pglogical
has pglogical_xact_commit_timestamp_origin() to get the replication
origin with its own function so providing an extending equivalent
returning one row with two fields would be nice for pglogical so as
this function is not necessary.  As mentioned by Madan, the portion of
the code using TransactionIdGetCommitTsData() relies on it for
conflicts of updates (the first win, last win logic at quick glance).

I am adding Peter E in CC for an opinion, the last commits of
pglogical are from him.
--
Michael

  6. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-06-30T05:57:40Z

    >> A second thing is that TransactionIdGetCommitTsData() was introdued in
>> core(73c986add). It has only one caller pg_xact_commit_timestamp() which
>> passes RepOriginId as NULL, making last argument to the
>> TransactionIdGetCommitTsData() a dead code in core.
>>
>> Quick code search shows that it is getting used by pglogical (caller:
>> https://sources.debian.org/src/pglogical/2.3.2-1/pglogical_conflict.c/?hl=509#L509).
>> CCing Craig Ringer and Petr Jelinek for the inputs.
 
>Another question that has popped up when doing this review is what
>would be the use-case of adding this information at SQL level knowing
>that logical replication exists since 10?  Having dead code in the
>backend tree is not a good idea of course, so we can also have as
>argument to simplify TransactionIdGetCommitTsData().  Now, pglogical
>has pglogical_xact_commit_timestamp_origin() to get the replication
>origin with its own function so providing an extending equivalent
>returning one row with two fields would be nice for pglogical so as
>this function is not necessary.  As mentioned by Madan, the portion of
>the code using TransactionIdGetCommitTsData() relies on it for
>conflicts of updates (the first win, last win logic at quick glance).

Thanks for the explanation, the origin in commit_ts seems useless, I am just
want to know why it appears there. It's ok to close this issue if we do not
want to touch it now.

And I am more interest in origin in wal, if data from a logical replicate or a 
manual origin then many wal records will get a 'RepOriginId',  'RepOriginId'
in 'xact' wal record may help to do some filter, the other same dead code
too. So can you help me to understand why or the historical reason for that?




Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  7. Re: A patch for get origin from commit_ts.

    Simon Riggs <simon@2ndquadrant.com> — 2020-06-30T12:58:17Z

    On Tue, 30 Jun 2020 at 02:17, Madan Kumar <madankumar1993@gmail.com> wrote:


> We already have pg_xact_commit_timestamp() that returns the timestamp of
> the commit.


Yes, pg_xact_commit_origin() is a good name for an additional function. +1
for this.


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

-- 
Simon Riggs                http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases

  8. Re: A patch for get origin from commit_ts.

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2020-06-30T18:32:47Z

    On 2020-Jun-30, Michael Paquier wrote:

> Another question that has popped up when doing this review is what
> would be the use-case of adding this information at SQL level knowing
> that logical replication exists since 10?

Logical replication in core is a far cry from a fully featured
replication solution.  Kindly do not claim that we can now remove
features just because in-core logical replication does not use them;
this argument is ignoring the fact that we're still a long way from
developing actually powerful logical replication capabilities.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  9. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-02T01:50:46Z

    On Tue, Jun 30, 2020 at 02:32:47PM -0400, Alvaro Herrera wrote:
> On 2020-Jun-30, Michael Paquier wrote:
>> Another question that has popped up when doing this review is what
>> would be the use-case of adding this information at SQL level knowing
>> that logical replication exists since 10?
> 
> Logical replication in core is a far cry from a fully featured
> replication solution.  Kindly do not claim that we can now remove
> features just because in-core logical replication does not use them;
> this argument is ignoring the fact that we're still a long way from
> developing actually powerful logical replication capabilities.

Thanks for the feedback.  If that sounded aggressive in some way, this
was not my intention, so my apologies for that.  Now, I have to admit
that I am worried to see in core code that stands as dead without any
actual way to test it directly.  Somebody hacking this code cannot be
sure if they are breaking it or not, except if they test it with
pglogical.  So it is good to close the gap here.  It also brings a
second point IMO, could the documentation be improved to describe more 
use-cases where these functions would be useful?  The documentation
gap is not a problem this patch has to deal with, though.
--
Michael

  10. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-02T01:58:52Z

    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?
--
Michael

  11. Re: A patch for get origin from commit_ts.

    Simon Riggs <simon@2ndquadrant.com> — 2020-07-02T07:52:45Z

    On Thu, 2 Jul 2020 at 02: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?
>

OK

-- 
Simon Riggs                http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases

  12. Re: A patch for get origin from commit_ts.

    Petr Jelinek <petr@2ndquadrant.com> — 2020-07-02T08:12:02Z

    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/

  13. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-03T05:10:59Z

    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

  14. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-04T05:44:49Z

    >Thanks.  Movead, please note that the patch is waiting on author? 

>Could you send an update if you think that those changes make sense? 

Thanks for approval the issue, I will send a patch at Monday. 
Regards,

Highgo Software (Canada/China/Pakistan) 

URL : http://www.highgo.ca/ 

EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  15. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-04T10:01:28Z

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

I make a patch as Michael Paquier described that use a new function to
return transactionid and origin, and I add a origin version to 
pg_last_committed_xact() too,  now it looks like below:

============================================
postgres=# SELECT txid_current() as txid \gset
postgres=# SELECT * FROM  pg_xact_commit_timestamp_origin(:'txid');
           timestamp                           |   origin 
-------------------------------------+--------
 2020-07-04 17:52:10.199623+08 |      1
(1 row)

postgres=# SELECT * FROM pg_last_committed_xact_with_origin();
 xid  |           timestamp                          | origin 
-----+------------------------------------+--------
 506 | 2020-07-04 17:52:10.199623+08 |      1
(1 row)

postgres=#
============================================

---
Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  16. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-06T00:36:35Z

    On Sat, Jul 04, 2020 at 06:01:28PM +0800, movead.li@highgo.ca wrote:
> I make a patch as Michael Paquier described that use a new function to
> return transactionid and origin, and I add a origin version to 
> pg_last_committed_xact() too,  now it looks like below:

+SELECT pg_replication_origin_create('test_commit_ts: get_origin_1');
+SELECT pg_replication_origin_create('test_commit_ts: get_origin_2');
+SELECT pg_replication_origin_create('test_commit_ts: get_origin_3');

Why do you need three replication origins to test three times the same
pattern?  Wouldn't one be enough and why don't you check after the
timestamp?  I would also two extra tests: one with a NULL input and an
extra one where the data could not be found.

+   found = TransactionIdGetCommitTsData(xid, &ts, &nodeid);
+
+   if (!found)
+       PG_RETURN_NULL();

This part also looks incorrect to me, I think that you should still
return two tuples, both marked as NULL.  You can do that just by
switching the nulls flags to true for the two values if nothing can be
found.
--
Michael

  17. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-06T03:12:30Z

    >+SELECT pg_replication_origin_create('test_commit_ts: get_origin_1');
>+SELECT pg_replication_origin_create('test_commit_ts: get_origin_2');
>+SELECT pg_replication_origin_create('test_commit_ts: get_origin_3');
>
>Why do you need three replication origins to test three times the same
>pattern?  Wouldn't one be enough and why don't you check after the
>timestamp?  I would also two extra tests: one with a NULL input and an
>extra one where the data could not be found.
> 
>+   found = TransactionIdGetCommitTsData(xid, &ts, &nodeid);
>+
>+   if (!found)
>+       PG_RETURN_NULL();
> 
>This part also looks incorrect to me, I think that you should still
>return two tuples, both marked as NULL.  You can do that just by
>switching the nulls flags to true for the two values if nothing can be
>found.
Thanks for the points and follow them, new patch attached.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  18. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-06T08:01:36Z

    On Mon, Jul 06, 2020 at 11:12:30AM +0800, movead.li@highgo.ca wrote:
> Thanks for the points and follow them, new patch attached.

That was fast, thanks.  I have not tested the patch, but there are
two things I missed a couple of hours back.  Why do you need
pg_last_committed_xact_with_origin() to begin with?  Wouldn't it be
more simple to just add a new column to pg_last_committed_xact() for
the replication origin?  Contrary to pg_xact_commit_timestamp() that
should not be broken for compatibility reasons because it returns only
one value, we don't have this problem with pg_last_committed_xact() as
it already returns one tuple with two values.

+{ oid => '4179', descr => 'get commit origin of a transaction',

A second thing is that the OID of the new function should be in the 
range 8000..9999, as per the policy introduced in commit a6417078.
src/include/catalog/unused_oids can be used to pick up a value.
--
Michael

  19. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-07T02:02:29Z

    >That was fast, thanks.  I have not tested the patch, but there are
>two things I missed a couple of hours back.  Why do you need
>pg_last_committed_xact_with_origin() to begin with?  Wouldn't it be
>more simple to just add a new column to pg_last_committed_xact() for
>the replication origin?  Contrary to pg_xact_commit_timestamp() that
>should not be broken for compatibility reasons because it returns only
>one value, we don't have this problem with pg_last_committed_xact() as
>it already returns one tuple with two values.
Yes make sense, changed in new patch.
 
>+{ oid => '4179', descr => 'get commit origin of a transaction',
>A second thing is that the OID of the new function should be in the
>range 8000..9999, as per the policy introduced in commit a6417078.
>src/include/catalog/unused_oids can be used to pick up a value.
Thanks, very helpful information and I have follow that.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  20. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-07T05:35:48Z

    On Tue, Jul 07, 2020 at 10:02:29AM +0800, movead.li@highgo.ca wrote:
> Thanks, very helpful information and I have followed that.

Cool, thanks.  I have gone through your patch in details, and updated
it as the attached.  Here are some comments.

'8000' as OID for the new function was not really random, so to be
fair with the other patches, I picked up the first random value
unused_oids has given me instead.

There were some indentation issues, and pgindent got that fixed.

I think that it is better to use "replication origin" in the docs
instead of just origin.  I have kept "origin" in the functions for
now as that sounded cleaner to me, but we may consider using something
like "reporigin" as well as attribute name.

The tests could just use tstzrange() to make sure that the timestamps
have valid values, so I have switched to that, and did not resist to
do the same in the existing tests.

+-- Test when it can not find the transaction
+SELECT * FROM pg_xact_commit_timestamp_origin((:'txid_set_origin'::text::int +
10)::text::xid) x;
This test could become unstable, particularly if it gets used in a
parallel environment, so I have removed it.  Perhaps I am just
over-pessimistic here though..

As a side note, I think that we could just remove the alternate output
of commit_ts/, as it does not really get used because of the
NO_INSTALLCHECK present in the module's Makefile.  That would be the
job of a different patch, so I have updated it accordingly.  Glad to
see that you did not forget to adapt it in your own patch.

(The change in catversion.h is a self-reminder...)
--
Michael

  21. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-08T01:31:24Z

    >Cool, thanks.  I have gone through your patch in details, and updated
>it as the attached.  Here are some comments.
 
>'8000' as OID for the new function was not really random, so to be
>fair with the other patches, I picked up the first random value
>unused_oids has given me instead.
> 
>There were some indentation issues, and pgindent got that fixed.
 
>I think that it is better to use "replication origin" in the docs
>instead of just origin.  I have kept "origin" in the functions for
>now as that sounded cleaner to me, but we may consider using something
>like "reporigin" as well as attribute name.
> 
>The tests could just use tstzrange() to make sure that the timestamps
>have valid values, so I have switched to that, and did not resist to
>do the same in the existing tests.
> 
>+-- Test when it can not find the transaction
>+SELECT * FROM pg_xact_commit_timestamp_origin((:'txid_set_origin'::text::int +
>10)::text::xid) x;
>This test could become unstable, particularly if it gets used in a
>parallel environment, so I have removed it.  Perhaps I am just
>over-pessimistic here though..
> 
>As a side note, I think that we could just remove the alternate output
>of commit_ts/, as it does not really get used because of the
>NO_INSTALLCHECK present in the module's Makefile.  That would be the
>job of a different patch, so I have updated it accordingly.  Glad to
>see that you did not forget to adapt it in your own patch.
> 
>(The change in catversion.h is a self-reminder...)
Thanks for all of that, so many details I still need to pay attention when 
submit a patch.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  22. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-08T01:51:24Z

    On Wed, Jul 08, 2020 at 09:31:24AM +0800, movead.li@highgo.ca wrote:
> Thanks for all of that, so many details I still need to pay attention when 
> submit a patch.

No problem.  We are all here to learn, and nothing can be perfect, if
perfection is even possible :)

Regarding the attribute name, I was actually considering to just use
"roident" instead.  This is more consistent with pglogical, and that's
also the field name we use in ReplicationState[OnDisk].  What do you
think?
--
Michael

  23. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-08T02:11:28Z

    >Regarding the attribute name, I was actually considering to just use
>"roident" instead.  This is more consistent with pglogical, and that's
>also the field name we use in ReplicationState[OnDisk].  What do you
>think?
Yes that's is the right way, I can see it's 'roident' in pg_replication_origin
catalog too.
What's your v6 patch based on, I can not apply it.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  24. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-08T06:08:24Z

    On Wed, Jul 08, 2020 at 10:11:28AM +0800, movead.li@highgo.ca wrote:
> Yes that's is the right way, I can see it's 'roident' in pg_replication_origin
> catalog too.
> What's your v6 patch based on, I can not apply it.

There is a conflict in catversion.h.  If you wish to test the patch,
please feel free to use the attached where I have updated the
attribute name to roident.
--
Michael

  25. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-09T02:04:23Z

    >There is a conflict in catversion.h.  If you wish to test the patch,
>please feel free to use the attached where I have updated the
>attribute name to roident.
I think everything is ok, but be careful the new patch is in Windows
format now.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  26. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-09T05:37:46Z

    On Thu, Jul 09, 2020 at 10:04:23AM +0800, movead.li@highgo.ca wrote:
> but be careful the new patch is in Windows format now.

That would be surprising.  Why do you think that?
--
Michael

  27. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-09T06:19:46Z

    >> but be careful the new patch is in Windows format now. 
>That would be surprising.  Why do you think that?
I am not sure why, I can not apply your patch, and I open it
with vscode and shows a CRLF format, if I change the patch to
LF then nothing wrong.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  28. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-09T06:33:28Z

    On Thu, Jul 09, 2020 at 02:19:46PM +0800, movead.li@highgo.ca wrote:
> I am not sure why, I can not apply your patch, and I open it
> with vscode and shows a CRLF format, if I change the patch to
> LF then nothing wrong.

This looks like an issue in your environment, like with git's autocrlf
or such?  rep-origin-superuser-v7.patch has no CRLF.
--
Michael

  29. Re: A patch for get origin from commit_ts.

    movead.li@highgo.ca <movead.li@highgo.ca> — 2020-07-09T06:42:30Z

    >> I am not sure why, I can not apply your patch, and I open it
>> with vscode and shows a CRLF format, if I change the patch to
>> LF then nothing wrong.
 
>This looks like an issue in your environment, like with git's autocrlf
>or such?  rep-origin-superuser-v7.patch has no CRLF.
Yes thanks, that's my environment problem.



Regards,
Highgo Software (Canada/China/Pakistan) 
URL : www.highgo.ca 
EMAIL: mailto:movead(dot)li(at)highgo(dot)ca

  30. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-10T01:06:06Z

    On Wed, Jul 08, 2020 at 03:08:24PM +0900, Michael Paquier wrote:
> There is a conflict in catversion.h.  If you wish to test the patch,
> please feel free to use the attached where I have updated the
> attribute name to roident.

Please note that I have switched the patch as ready for committer.  So
I'll try to get that done, with roident as attribute name.  If
somebody prefers a different name or has an objection, please feel
free to chime in.
--
Michael

  31. Re: A patch for get origin from commit_ts.

    Michael Paquier <michael@paquier.xyz> — 2020-07-12T12:42:26Z

    On Fri, Jul 10, 2020 at 10:06:06AM +0900, Michael Paquier wrote:
> Please note that I have switched the patch as ready for committer.  So
> I'll try to get that done, with roident as attribute name.  If
> somebody prefers a different name or has an objection, please feel
> free to chime in.

Hearing nothing, committed after fixing few things:
- The docs reversed <parameter> and <type>.
- The comment on top of GetLatestCommitTsData() mentioned "extra"
instead of "nodeid".  Not an issue of this patch but I have just fixed
it.
- We could just have used memset for nulls when the data could not be
found in pg_xact_commit_timestamp_origin().
- Added some casts to Oid for the new ObjectIdGetDatum() calls.
- Changed the tests to not show numerical values for roident, checking
instead that the values are non-zero for the cases where we don't
expect a valid replication origin.  For the valid cases, I have just
used a join with pg_replication_origin to grab roname.  This makes the
tests more portable.

After applying the patch as of b1e48bb, longfin has also complained
that regression tests should prefix replication origins with
"regress_".  This has been fixed with ea3e15d.
--
Michael