Re: PATCH: 9.5 replication origins fix for logical decoding - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: PATCH: 9.5 replication origins fix for logical decoding
Date
Msg-id CAMsr+YFcAGV3s9Gt6QN9y8VGok9hBPzKz28sgSdmTCcFVRb3fw@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: 9.5 replication origins fix for logical decoding  (Andres Freund <andres@anarazel.de>)
Responses Re: PATCH: 9.5 replication origins fix for logical decoding
List pgsql-hackers
On 15 October 2015 at 17:43, Andres Freund <andres@anarazel.de> wrote:

>> I guess since it'll be InvalidRepOriginId otherwise, that makes sense.
>
> That's not the point. XACT_XINFO_HAS_ORIGIN is about
> origin_lsn/timestamp, it doesn't have anything to do with the record
> origin (which is included in many more types of record than just
> commits).

Ok, I think I see. That's also why it wasn't incorporated into
xl_xact_parsed_commit.

I'll check which records can contain it and assign it in the
appropriate decoding calls. I'll follow up in a while with an updated
patch.

>> > Your test prints the origins from the transaction instead the changes -
>> > why?
>>
>> I don't understand this part.
>
> Your test prints origin in commits - but changes can have individual
> origins.

I was completely unaware of that, so thankyou. I'll change the tests
to exercise that. Any preferences on the output format?

Maybe:

table public.origin_tbl: INSERT: id[integer]:6 data[text]:'from second
origin' -- origin:'some_origin' origin_lsn:'0/1234'

?

it's cluttered, but really I'm not sure there's a pretty way to pack
that in, and it's only test output.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan
Next
From: Andres Freund
Date:
Subject: Re: PATCH: 9.5 replication origins fix for logical decoding