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 →
-
postgres_fdw: Replace buffers in RemoteAttributeMapping with pointers.
- aa1f93a3387a 19 (unreleased) landed
-
Add support for importing statistics from remote servers.
- 28972b6fc3dc 19 (unreleased) landed