From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: 9.5 replication origins fix for logical decoding |
Date: | 2015-10-15 12:52:41 |
Message-ID: | CAMsr+YHk-Eki1+S7DvsXmfjrpt6zTBvMaMqseMrNkpqnLhG2eQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15 October 2015 at 20:11, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 15 October 2015 at 19:04, Andres Freund <andres(at)anarazel(dot)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 | Content-Type | Size |
---|---|---|
0001-Decode-replication-origin-in-commit.patch | text/x-patch | 12.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-10-15 12:55:36 | Re: PATCH: 9.5 replication origins fix for logical decoding |
Previous Message | Amit Kapila | 2015-10-15 12:45:20 | Re: Parallel Seq Scan |