Re: Add publisher and subscriber to glossary documentation.

On Thu, Mar 14, 2024 at 7:51 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2024-Mar-14, Shlok Kyal wrote:
>
> > Andrew Atkinson wrote:
> >
> > > Anyway, hopefully these examples show “node” and “database” are
> > > mixed and perhaps others agree using one consistently might help the
> > > goals of the docs.
> >
> > For me the existing content looks good, I felt let's keep it as it is
> > unless others feel differently.
>
> Actually it's these small terminology glitches that give me pause. If
> we're going to have terms that are interchangeable (in this case "node"
> and "database"), then they should be always interchangeable, not just in
> some unspecified cases. Maybe the idea of using "node" (which sounds
> like something that's instance-wide) is wrong for logical replication,
> which is necessarily something that happens database-locally.
>
> Then again, maybe defining "node" as something that exists at a
> database-local level when used in the context of logical replication is
> sufficient. In that case, it would be better to avoid defining it as a
> synonym of "instance". Then the terms are not always interchangeable,
> but it's clear when they are and when they aren't.
>
> "Node: in <glossterm>replication</>, each of the endpoints to which or
> from which data is replicated. In the context of physical replication,
> each node is an instance. In the context of logical replication, each
> node is a database".
>

I think node should mean instance for both physical and logical
replication, otherwise, it would be confusing. We need both the usages
as a particular publication/subscription is defined at the database
level but the server on which we define those is referred to as a
node/instance.

One of the usages pointed out by Andrew: "The subscriber database..."
[1] is unclear but I feel we can use node there as well instead of
database.

[1] - https://www.postgresql.org/docs/current/logical-replication-subscription.html

--
With Regards,
Amit Kapila.