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.
Hearin
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. S
>> 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, tha
On Thu, Jul 09, 2020 at 02:19:46PM +0800, movead...@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 suc
>> 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/
On Thu, Jul 09, 2020 at 10:04:23AM +0800, movead...@highgo.ca wrote:
> but be careful the new patch is in Windows format now.
That would be surprising. Why do you think that?
--
Michael
signature.asc
Description: PGP signature
>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
On Wed, Jul 08, 2020 at 10:11:28AM +0800, movead...@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
>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
On Wed, Jul 08, 2020 at 09:31:24AM +0800, movead...@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
>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 w
On Tue, Jul 07, 2020 at 10:02:29AM +0800, movead...@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 ra
>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? Con
On Mon, Jul 06, 2020 at 11:12:30AM +0800, movead...@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
>+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?
On Sat, Jul 04, 2020 at 06:01:28PM +0800, movead...@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_cr
>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() t
>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
On Thu, Jul 02, 2020 at 10:12:02AM +0200, Petr Jelinek wrote:
> On 02/07/2020 03:58, mich...@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
On 02/07/2020 03:58, mich...@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 wrote:
It may be better to have one single function returning both
timestamp and origin for a given transaction ID.
No need to change existin
On Thu, 2 Jul 2020 at 02:58, wrote:
> On Tue, Jun 30, 2020 at 01:58:17PM +0100, Simon Riggs wrote:
> > On Tue, 30 Jun 2020 at 02:17, Madan Kumar
> wrote:
> >> It may be better to have one single function returning both
> >> timestamp and origin for a given transaction ID.
> >
> > No need to chan
On Tue, Jun 30, 2020 at 01:58:17PM +0100, Simon Riggs wrote:
> On Tue, 30 Jun 2020 at 02:17, Madan Kumar 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 re
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?
>
> L
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
replicatio
On Tue, 30 Jun 2020 at 02:17, Madan Kumar 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
> times
>> 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
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 Transactio
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).
>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 'roi
On Mon, May 11, 2020 at 04:43:11PM +0800, movead...@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 th
30 matches
Mail list logo
