Possible replace of strncpy on xactdesc.c

Hi there,

I've been doing some research about if we could replace strncpy() in
some code. It seems I found one and I'd like your opinion on it to
determine if it's worth the change.

Basically what I found and IMO it's worth the change is on file xactdesc.c

diff --git a/src/backend/access/rmgrdesc/xactdesc.c
b/src/backend/access/rmgrdesc/xactdesc.c
index 4f53d3035cc..0f466a4c27c 100644
--- a/src/backend/access/rmgrdesc/xactdesc.c
+++ b/src/backend/access/rmgrdesc/xactdesc.c
@@ -256,7 +256,7 @@ ParsePrepareRecord(uint8 info, xl_xact_prepare
*xlrec, xl_xact_parsed_prepare *p
parsed->nabortstats = xlrec->nabortstats;
parsed->nmsgs = xlrec->ninvalmsgs;

- strncpy(parsed->twophase_gid, bufptr, xlrec->gidlen);
+ strlcpy(parsed->twophase_gid, bufptr, sizeof(parsed->twophase_gid));
bufptr += MAXALIGN(xlrec->gidlen);

First of all, I noticed the `memset(parsed, 0, sizeof(*parsed));` that
existed previously, which initially made me think twice about sending
this. Also, thanks to the feedback of a friend, I learnt a previous
refactor of this code was introduced in:
7b8a899bdeb Make pg_waldump report more detail information about
PREPARE TRANSACTION record.

The other functions that are inside the file already use strlcpy() so
maybe the use of current strncpy() on xactdesc.c is just code that
comes from the refactor itself.

I see that `parsed` is a transient decode struct, freshly zeroed each
call by the memset() I talked about above. To me, it sounds safe to do
the swap. But I'm open to ideas.
I'll send a proper patch once some feedback is received but at least
it's compiling and passing local tests.

Thanks!

--
Mario Gonzalez
EDB: https://www.enterprisedb.com