Hi, On Mon, Aug 17, 2026 at 3:21 PM Masahiko Sawada <[email protected]> wrote: > > > > > It doesn't have to be exactly 39; 1024 (long enough) would also work, > > > > or perhaps something based on UUID_LEN, such as UUID_LEN * 3. I think > > > > the main point is to avoid unbounded scanning on malformed input. > > > > > > > > The old code did not have this issue because it only examined as much > > > > input as needed based on UUID_LEN. The new fast path starts to use > > > > strlen(), so this would be a new risk introduced by the optimization. > > > > > > I don't think the scan can be really unbounded. string_to_uuid() > > > receives a cstring, so by the time it is called the caller has already > > > walked or copied the whole string to produce it. So unless the > > > unbounded scan can be reached in some path I have overlooked, I'd > > > prefer to keep strlen() here. Happy to change it if you still think it > > > is worth it. > > > > After more thoughts, while I still don't think the scan can be > > unbounded, using strlen() would add an extra scan just to determine we > > use hex_decode_safe(). I'll change it to use strnlen() instead. > > I've updated the patch accordingly. Please review it.
I reviewed the diff and the v5 patch looks good. Bounding the strlen to 64 bytes seems fine. pgindent, make check, and make check-world are all clean. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
