Thread: A patch for get origin from commit_ts.

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

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"

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

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

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

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

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/

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

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

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

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

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

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

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

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

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

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