Hello
I have a couple of API-level reservation about this patch series.
Firstly, "behind" when used as a noun refers to buttocks. Therefore,
the ReplicationSlotsEnumerateBehinds function name seems funny (I think
when used as a preposition you wouldn't put it in plural). I don't
suggest a substitute name, because the API itself doesn't convince me; I
think it would be sufficient to have it return a single slot name,
perhaps the one that is behind the most ... or maybe the one that is
behind the least? This simplifies a lot of code (in particular you do
away with the bunch of statics, right?), and I don't think the warning
messages loses anything, because for details the user should really look
into the monitoring view anyway.
I didn't like GetLsnAvailability() returning a string either. It seems
more reasonable to me to define a enum with possible return states, and
have the enum value be expanded to some string in
pg_get_replication_slots().
In the same function, I think that setting restBytes to -1 when
"useless" is bad style. I would just leave that variable alone when the
returned status is not one that receives the number of bytes. So the
caller is only entitled to read the value if the returned enum value is
such-and-such ("keeping" and "streaming" I think).
I'm somewhat uncomfortable with the API change to GetOldestKeepSegment
in 0002. Can't its caller do the math itself instead?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
