Re: Replication identifiers, take 4

On April 24, 2015 10:26:23 PM GMT+02:00, Peter Eisentraut <peter_e@gmx.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
otherside's slots also aren't going to be backed up as pg dump obviously can't know about then. So the represented data
won'tmake much sense.
 


Andres

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