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+YHk-Eki1+S7DvsXmfjrpt6zTBvMaMqseMrNkpqnLhG2eQ@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: 9.5 replication origins fix for logical decoding  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: PATCH: 9.5 replication origins fix for logical decoding  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 15 October 2015 at 20:11, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 15 October 2015 at 19:04, Andres Freund <andres@anarazel.de> wrote:
>
>> As far as I can see all the other places have it assigned.
>
> Ok, thanks. Not much need for a followup patch then, if you're not
> using the test changes part.

Here's what I used for my tests, anyway, including an updated fix.

You'll note that the tests fail. When the replication origin is reset
and set again with pg_replication_origin_xact_setup mid-xact, the
origin identity exposed to the decoding plugin callbacks for all
records (including those created before the origin change) is the
latter origin, the one active at COMMIT time.

Is that the intended behaviour? That the session identifier is
determined by what was active at commit time, and only the lsn and
timestamp vary throughout the xact? It looks like it from the code.

Should pg_replication_origin_xact_reset() and
pg_replication_origin_xact_setup() be permitted within a transaction?
Or is this just a "well, don't do that"?

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

Attachment

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