Re: Replication identifiers, take 4

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication identifiers, take 4
Date: 2015-04-21 15:20:42
Message-ID: 20150421152042.GC4369@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-04-21 15:30:27 Re: Replication identifiers, take 4
Previous Message Sawada Masahiko 2015-04-21 15:15:53 Re: Freeze avoidance of very large table.