From: Tom Lane <tgl@sss.pgh.pa.us>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
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
Subject: Re: Import Statistics in postgres_fdw before resorting to sampling.
In-reply-to: 
 <CAPmGK14jxz8HsXq275b1VK-oLRKa2FXiq+i_fRDBVSuOTb+fMw@mail.gmail.com>
References: 
 <CADkLM=chrYAx=X2KUcDRST4RLaRLivYDohZrkW4LLBa0iBhb5w@mail.gmail.com>
 <CAExHW5seoMNjHiZge0O=p-oF6PGsY8om4VjpzTCBsaASXZC6Fw@mail.gmail.com>
 <CADkLM=feCJrEDWCOpoxxg58J_6zX6nv+BnXufUOEZuP7bYTCbg@mail.gmail.com>
 <CADkLM=d8+FwmbH0imhPOw=VGEASL4Q8tsCFjNcnfbU7sSWm0ig@mail.gmail.com>
 <CADkLM=cVc-KUAqcm1yoDkGwMrcgCvxY3WAMpaRZVLtO9sbc+kg@mail.gmail.com>
 <aPXaeowZ6RBPlsrD@paquier.xyz>
 <CADkLM=dSJk8h+14Wi7dGGcO1168R_nCGO2EHRTcC6b2Zu0rhpg@mail.gmail.com>
 <CAPmGK15Lk0ynP_b46sgfV1pmByzWUKVQoZBSV8fbN0rKb_6AnA@mail.gmail.com>
 <CADkLM=foU7yK1rfMzqTPiQtfEOGANAS9dHE5-Js6hEXmZiKfow@mail.gmail.com>
 <CADkLM=eDJiXe58+fXiFqp8Zyrh-E28mU11U53rVGjx0AQFzBKw@mail.gmail.com>
 <CAPmGK15jEDCeMXE=EEuA5-1tC2xg5WYSjWzPGpcz+udHBT4bUA@mail.gmail.com>
 <CADkLM=fRF2w-_fMyztS0R4e9YVH8tamHXMsBBVhFsSHoJKrKXg@mail.gmail.com>
 <CAPmGK17Dfjy_zLH1yjPqybpSueHWP7Gy_xBZXA2NpRso1qya7A@mail.gmail.com>
 <CADkLM=fb=FsBLqNc14-y4na57ypywZxYb4q-zrxcaY6qQW0B2Q@mail.gmail.com>
 <CADkLM=dfuT8YgXOyoXW7nuGdOFw-sYh2uR3hQS-N66Gj_k_!
 ytw@mail.gmail.com>
 <CAPmGK17v-qJL5j2Z25jD33vKLyhAnNppYsy5UTbEAwAeBP=vGQ@mail.gmail.com>
 <CAPmGK15iR8M55_Fi6PZyvSH5-4B-R2n2YvvhRJB8Pm2cxxrF1w@mail.gmail.com>
 <CADkLM=cVZH+SDUuvsyMHzuWTK5XkK1i_L5dgTNrgRXWN1S-syQ@mail.gmail.com>
 <CAPmGK16AQzGsEe6pD7m42AO1KRCuXQu=U_abXaAf3juCS5U+mA@mail.gmail.com>
 <CADkLM=ezV0_oUCxK=A2TmaAuXvWs0+i-H8fSNU3BRY=dBuDhQQ@mail.gmail.com>
 <CAExHW5sV1tKES6A=T-auzHtoOMKO-wurUqEHFbOgZJ-jBnxuxw@mail.gmail.com>
 <CADkLM=ce0qES4suTDaTmjLXekGcuNwirYBNFDFb-iY8fX8-xpA@mail.gmail.com>
 <CAExHW5uEicRpM0cxEgX_0PL41V6OcHUa0v3BOdBzsQOQcBuh=Q@mail.gmail.com>
 <CADkLM=d1HH1JnhCmpD+3v+A=JZ4EeQRa86Ygfaucb1zKpS1vWw@mail.gmail.com>
 <CAExHW5sXi9gEQkB_7bk+3R6mnEm3oYO2vRVOS9_ZSY13+g1Bzg@mail.gmail.com>
 <CADkLM=d5vmtZGnBC-Em-oiPi+EHYWzK1uWK4WLP_iyGnYPNGPA@mail.gmail.com>
 <CADkLM=e=UERdCRRxs9vf=jssu9NTV+gr6N4bwdmFg0SRAXqKhw@mail.gmail.com>
 <CAPmGK17_g=iV+krUxxfpUfP1MZLm_-DGy7ZCgRQRxz48sJgvmw@mail.gmail.com>
 <CADkLM=dwNKqD21UERHJuDwQ_MK1Bz8=9qz+r17A0U0W9zwHsUg@mail.gmail.com> <C!
 APmGK15=wn5G12oS7R-0gX6EvcOG5bDZ6ZJCB6w-ddNRUStKAg@mail.gmail.com>
 <CADkLM=f8bQXJqPym7Sqk3sOBDkjOULz2h58n0+y-cGA3XfNJ8Q@mail.gmail.com>
 <CAPmGK17+FS99X7t8_T2pL-seSOP_dYoQi7jOhshf8LKFzJgrwg@mail.gmail.com>
 <CADkLM=diN=GaKxVZF=rD3hFpYCwEfg-n6nY+aC4FNsOCeAkPBw@mail.gmail.com>
 <CADkLM=eozfsr-2hmuhBa71ATizWo7LQ01ZkJFbDqCKwC-f7ZHQ
Comments: In-reply-to Etsuro Fujita <etsuro.fujita@gmail.com>
	message dated "Wed, 08 Apr 2026 20:24:00 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <342867.1776017700.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 12 Apr 2026 14:15:00 -0400
Message-ID: <342868.1776017700@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/342868.1776017700%40sss.pgh.pa.us>
Precedence: bulk

Etsuro Fujita <etsuro.fujita@gmail.com> writes:
> Pushed.  I closed the CF entry as well.

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 dest=
ination array "remattrmap[attrcnt].local_attname" of size 64 bytes might l=
eave the destination string unterminated.
5960     		strncpy(remattrmap[attrcnt].local_attname, attname, NAMEDATALEN=
);
5961     		strncpy(remattrmap[attrcnt].remote_attname, remote_attname, NAM=
EDATALEN);

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/.

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

			regards, tom lane