On Mon, Jun 15, 2020 at 8:23 PM Andres Freund <andres@anarazel.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).
