| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Pallavi Sontakke <pallavi(dot)sontakke(at)2ndquadrant(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
| Subject: | Re: PATCH: 9.5 replication origins fix for logical decoding |
| Date: | 2015-10-16 04:25:40 |
| Message-ID: | CAMsr+YHzU7mnh5cbo6_ZwCR+vpRN7miy=ZqE-Bt8BNaz_Au3Fg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16 October 2015 at 11:51, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> Document it as a "don't do that, if you do it you get to keep the pieces"?
Thinking about this some more, having per-change origins makes sense
when you're not using origin LSNs, such as when you're not replaying
from another PostgreSQL instance. So I _can_ see why it exists.
I guess this is mostly a matter of adding some comments and/or some
notes in the functions' docs to explain how it all fits together -
that origins can be per-change, that the txn origin is the origin that
was in effect at commit time, and that the lsn and commit timestamp
are always those that were set at commit time, so you cannot use a
per-change origin with the txn's lsn and expect it to make sense.
Reasonable?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2015-10-16 04:37:01 | Re: Parallel Seq Scan |
| Previous Message | Robert Haas | 2015-10-16 04:21:00 | Re: Parallel Seq Scan |