Re: Replication identifiers, take 4
От | Alvaro Herrera |
---|---|
Тема | Re: Replication identifiers, take 4 |
Дата | |
Msg-id | 20150421152042.GC4369@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Replication identifiers, take 4 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Replication identifiers, take 4
(Andres Freund <andres@anarazel.de>)
|
Список | pgsql-hackers |
Andres Freund wrote: > I'm working on changing this (I've implemented the missing WAL > bits). I'd like to discuss the new terms for a sec, before I go and > revise the docs. > > I'm now calling the feature 'replication progress tracking'. There's > "replication origins" and there's progress tracking infrastructure that > tracks how far data from a "replication origin" has replicated. Sounds good to me. > Catalog wise there's an actual table 'pg_replication_origin' that maps > between 'roident' and 'roname'. There's a pg_replication_progress view > (used to be named pg_replication_identifier_progress). I'm not sure if > the latter name isn't too generic? Maybe > pg_logical_replication_progress? I think if we wanted "pg_logical_replication_progress" (and I don't really agree that we do) then we would add the "logical" bit to the names above as well. This seems unnecessary. pg_replication_progress seems okay to me. > I've now named the functions: > > * pg_replication_origin_create > * pg_replication_origin_drop > * pg_replication_origin_get (map from name to id) > * pg_replication_progress_setup_origin : configure session to replicate > from a specific origin > * pg_replication_progress_reset_origin > * pg_replication_progress_is_replaying : Is a origin configured for the session > * pg_replication_progress_advance : "manually" set the replication > progress to a value. Primarily useful for copying values from other > systems and such. These all look acceptable to me. > * pg_replication_progress_get : How far did replay progress for a > certain origin > * pg_get_replication_progress : SRF returning the replay progress for > all origin. This combination seems confusing. In some other thread not too long ago there was the argument that "all functions 'get' something, so that verb should not appear in the function name". That would call for "pg_replication_progress" on the singleton. Maybe to distinguish the SRF, add "all" as a suffix? > * pg_replication_progress_setup_tx_details : configure per transaction > details (LSN and timestamp currently) Not sure about the "tx" here. We use "xact" as an abbreviation for "transaction" in most places. If nowadays we don't like that term, maybe just spell out "transaction" in full. I assume this function pairs up with pg_replication_progress_setup_origin, yes? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: