Re: Replication identifiers, take 4

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Replication identifiers, take 4
Дата
Msg-id 553AA6EF.70209@gmx.net
обсуждение исходный текст
Ответ на Re: Replication identifiers, take 4  (Andres Freund <andres@anarazel.de>)
Ответы Re: Replication identifiers, take 4  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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?)?





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Feedback on getting rid of VACUUM FULL
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Reducing tuple overhead