| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, "isaac(dot)morland(at)gmail(dot)com" <isaac(dot)morland(at)gmail(dot)com> |
| Subject: | Re: Maximum password length |
| Date: | 2020-09-01 20:15:59 |
| Message-ID: | D0B58EB2-B905-4994-B48A-AEA351B60449@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/31/20, 5:55 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I set the proposed limit at 1024 bytes, but given that we now know
> of use-cases needing up to 800 bytes, maybe there should be a little
> more headroom? I don't want to make it enormous, though, seeing that
> we're allocating static buffers of that size.
For the use-case described in [0], I ended up bumping the server-side
limit in libpq/auth.c to 8192 bytes for RDS instances. This appears
to be the PqRecvBuffer size, too. In any case, these tokens regularly
exceed 1024 bytes, so I would definitely argue for more headroom if
possible. Otherwise, I like the idea of unifying all the limits.
Nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-09-01 21:08:25 | Re: v13: show extended stats target in \d |
| Previous Message | Jeff Davis | 2020-09-01 19:58:59 | Re: Disk-based hash aggregate's cost model |