On 2015-04-21 12:20:42 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > 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.
Cool.
> > * 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.
Hm. I don't like that. That'd e.g. clash with the above view. I think
it's good to distinguish between functions (that have a verb in the
name) and views/tables (that don't).
I agree that the above combination isn't optimal. Although pg_get (and
pg_stat_get) is what's used for a lot of other SRF backed views. Maybe
naming the SRF pg_get_all_replication_progress?
> > * 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.
Oh, yea. Xact is more consistent.
> 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?
pg_replication_progress_setup_origin sets up the per session state,
setup_xact_details the "per replayed transaction" state.
Greetings,
Andres Freund