On 16 October 2015 at 11:51, Craig Ringer <cr...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
