Re: Import Statistics in postgres_fdw before resorting to sampling.

Etsuro Fujita <etsuro.fujita@gmail.com>

From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Corey Huinker <corey.huinker@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@postgresql.org, jkatz@postgresql.org, nathandbossart@gmail.com
Date: 2026-04-13T04:53:05Z
Lists: pgsql-hackers
On Sun, Apr 12, 2026 at 11:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Coverity doesn't like this patch's uses of strncpy():
>
> >>>     CID 1691464:           (BUFFER_SIZE)
> >>>     Calling "strncpy" with a maximum size argument of 64 bytes on destination array "remattrmap[attrcnt].local_attname" of size 64 bytes might leave the destination string unterminated.
> 5960                    strncpy(remattrmap[attrcnt].local_attname, attname, NAMEDATALEN);
> 5961                    strncpy(remattrmap[attrcnt].remote_attname, remote_attname, NAMEDATALEN);
>
> I think it's dead right to complain: remote_attname, in particular,
> could certainly be longer than NAMEDATALEN.
>
> AFAICS, postgres_fdw's subsequent uses of those strings only need
> them to be nul-terminated C strings, so strncpy's property of
> zero-filling the whole buffer is not needed here.  I recommend
> s/strncpy/strlcpy/.

Seems like a good idea.

> It's probably also appropriate to think about using pg_mbcliplen()
> to ensure that this code doesn't result in a broken multibyte
> character.

Will do.

I am currently overseas and will be attending an event this week, so I
will work on this after returning home.  In the meantime, I created an
entry for it in the open items list.

Thanks!

Best regards,
Etsuro Fujita



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. postgres_fdw: Replace buffers in RemoteAttributeMapping with pointers.

  2. Add support for importing statistics from remote servers.