Re: language cleanups in code and docs

On Mon, Jun 15, 2020 at 8:23 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> We've removed the use of "slave" from most of the repo (one use
> remained, included here), but we didn't do the same for master. In the
> attached series I replaced most of the uses.
>
> 0001: tap tests: s/master/primary/
> Pretty clear cut imo.
>
> 0002: code: s/master/primary/
> This also includes a few minor other changes (s/in master/on the
> primary/, a few 'the's added). Perhaps it'd be better to do those
> separately?
>
> 0003: code: s/master/leader/
> This feels pretty obvious. We've largely used the leader / worker
> terminology, but there were a few uses of master left.
>
> 0004: code: s/master/$other/
> This is most of the remaining uses of master in code. A number of
> references to 'master' in the context of toast, a few uses of 'master
> copy'. I guess some of these are a bit less clear cut.
>
> 0005: docs: s/master/primary/
> These seem mostly pretty straightforward to me. The changes in
> high-availability.sgml probably deserve the most attention.
>
> 0006: docs: s/master/root/
> Here using root seems a lot better than master anyway (master seems
> confusing in regard to inheritance scenarios). But perhaps parent
> would be better? Went with root since it's about the topmost table.
>
> 0007: docs: s/master/supervisor/
> I guess this could be a bit more contentious. Supervisor seems clearer
> to me, but I can see why people would disagree. See also later point
> about changes I have not done at this stage.
>
> 0008: docs: WIP multi-master rephrasing.
> I like neither the new nor the old language much. I'd welcome input.
>
>
> After this series there are only two widespread use of 'master' in the
> tree.
> 1) 'postmaster'. As changing that would be somewhat invasive, the word
> is a bit more ambiguous, and it's largely just internal, I've left
> this alone for now. I personally would rather see this renamed as
> supervisor, which'd imo actually would also be a lot more
> descriptive. I'm willing to do the work, but only if there's at least
> some agreement.
> 2) 'master' as a reference to the branch. Personally I be in favor of
> changing the branch name, but it seems like it'd be better done as a
> somewhat separate discussion to me, as it affects development
> practices to some degree.
>
>
In looking at this I realize we also have exactly one thing referred to as
"blacklist" in our codebase, which is the "enum blacklist" (and then a
small internal variable in pgindent). AFAICT, it's not actually exposed to
userspace anywhere, so we could probably make the attached change to
blocklist at no "cost" (the only thing changed is the name of the hash
table, and we definitely change things like that in normal releases with no
specific thought on backwards compat).

//Magnus