From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Fujii Masao <fujii(at)postgresql(dot)org> |
Subject: | Re: Remove line length restriction in passwordFromFile() |
Date: | 2020-09-01 05:41:09 |
Message-ID: | b2391bb7-33c5-a25e-e99a-81f7e96efdad@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020/09/01 10:00, Fujii Masao wrote:
>
>
> On 2020/09/01 6:24, Tom Lane wrote:
>> Per the discussion at [1], we're now aware of actual use-cases for
>> password strings approaching a kilobyte in length. I think this puts
>> the final nail in the coffin of the idea that passwordFromFile() can
>> use a fixed-length line buffer. Therefore, commit 2eb3bc588 (which
>> added a warning for overlength lines) seems rather misguided in
>> hindsight. What we should do instead is fix that code so it has no
>> hard upper bound on the line length.
>
> AFAIR, there were proposals to increase the maximum length of password so far,
> but we could not do that because we failed to get the consensus about
> that change. But if we get the clear use-case requiring longer password and
> reach the consensus, that's good news. I agree with the change.
>
>> Even if you want to say that
>> we'll set a particular limit on how long the password field can be,
>> there's no good upper bound for the length of the hostname field;
>> so ISTM that just getting out of the business of a fixed-size buffer
>> is the sanest way.
>>
>> Hence, the attached proposed patch does that, and for good measure
>> adds some testing of this formerly untested code.
The patch looks good to me, except the following minor thing.
+ if (fgets(buf.data + buf.len, buf.maxlen - buf.len - 1, fp) == NULL)
IIUC fgets() reads the data with the specified size - 1, so ISTM that -1 of
"buf.maxlen - buf.len - 1" is not necessary.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-09-01 05:51:58 | Re: 回复:how to create index concurrently on partitioned table |
Previous Message | Tom Lane | 2020-09-01 05:27:15 | Re: Use T_IntList for uint32 |