Re: Replication identifiers, take 4

On April 24, 2015 10:26:23 PM GMT+02:00, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>On 4/24/15 8:32 AM, Andres Freund wrote:
>> On 2015-04-20 11:26:29 +0300, Heikki Linnakangas wrote:
>>> On 04/17/2015 11:54 AM, Andres Freund wrote:
>>>> I've attached a rebased patch, that adds decision about origin
>logging
>>>> to the relevant XLogInsert() callsites for "external" 2 byte
>identifiers
>>>> and removes the pad-reusing version in the interest of moving
>forward.
>>>
>>> Putting aside the 2 vs. 4 byte identifier issue, let's discuss
>naming:
>>>
>>> I just realized that it talks about "replication identifier" as the
>new
>>> fundamental concept. The system table is called
>"pg_replication_identifier".
>>> But that's like talking about "index identifiers", instead of just
>indexes,
>>> and calling the system table pg_index_oid.
>>>
>>> The important concept this patch actually adds is the *origin* of
>each
>>> transaction. That term is already used in some parts of the patch. I
>think
>>> we should roughly do a search-replace of "replication identifier" ->
>>> "replication origin" to the patch. Or even "transaction origin".
>>
>> Attached is a patch that does this, and some more, renaming. That was
>> more work than I'd imagined. I've also made the internal naming in
>> origin.c more consistent/simpler and did a bunch of other cleanup.
>>
>> I'm pretty happy with this state.
>
>Shouldn't this be backed up by pg_dump(all?)?

Given it deals with LSNs and is, quite fundamentally due to concurrency, non transactional, I doubt it's worth it. The other side's slots also aren't going to be backed up as pg dump obviously can't know about then. So the represented data won't make much sense.

Andres

---
Please excuse brevity and formatting - I am writing this on my mobile phone.