Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name
Date
Msg-id 20190110004752.GC2157@paquier.xyz
Whole thread Raw
In response to Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Donald Dong <xdong@csumb.edu>)
Responses Re: Making WAL receiver startup rely on GUC context forprimary_conninfo and primary_slot_name  (Donald Dong <xdong@csumb.edu>)
List pgsql-hackers
On Wed, Jan 09, 2019 at 06:00:23AM -0800, Donald Dong wrote:
> I wonder why do we need to have this addition?
>
> src/backend/replication/walreceiver.c
> +       memset(walrcv->slotname, 0, NAMEDATALEN);
> +       if (PrimarySlotName)
> +               strlcpy((char *) walrcv->slotname, PrimarySlotName, NAMEDATALEN);
>

That's much cleaner to me to clean up the field for safety before
starting the process.  When requesting a WAL receiver to start,
slotname and conninfo gets zeroed before doing anything, you are right
that we could do without it actually.

> I notice these patterns appear in different places. Maybe it will be
> better to have a common method such as pg_str_empty()?

That's a pattern used quite a lot for many GUCs, so that's quite
separate from this patch.  Perhaps it would make sense to have a macro
for that purpose for GUCs, I am not sure if that's worth it though.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: some minor comment fix in md.c
Next
From: Michael Paquier
Date:
Subject: Re: Misleading panic message in backend/access/transam/xlog.c