Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qjkH6-00BuUu-CJ for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Sep 2023 17:49:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qjkH3-005Dry-Gr for pgsql-bugs@arkaria.postgresql.org; Fri, 22 Sep 2023 17:49:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qjkH3-005Drf-7H for pgsql-bugs@lists.postgresql.org; Fri, 22 Sep 2023 17:49:05 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qjkH0-0063qQ-OT for pgsql-bugs@lists.postgresql.org; Fri, 22 Sep 2023 17:49:03 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 38MHmxs01056585; Fri, 22 Sep 2023 13:48:59 -0400 From: Tom Lane To: Alvaro Herrera cc: uwe.binder@pass-consulting.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18080: to_tsvector fails for long text input In-reply-to: <3300287.1694786029@sss.pgh.pa.us> References: <202309151141.pq2zpi5kxdvn@alvherre.pgsql> <3300287.1694786029@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 15 Sep 2023 09:53:49 -0400" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1056570.1695404930.0@sss.pgh.pa.us> Date: Fri, 22 Sep 2023 13:48:59 -0400 Message-ID: <1056584.1695404939@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1056570.1695404930.1@sss.pgh.pa.us> I wrote: > Yeah. My thought about blocking the error had been to limit > prs.lenwords to MaxAllocSize/sizeof(ParsedWord) in this code. Concretely, as attached. This allows the given test case to complete, since it doesn't actually create very many distinct words. In other cases we could expect to fail when the array has to get enlarged, but that's just a normal implementation limitation. I looked for other places that might initialize lenwords to not-sane values, and didn't find any. BTW, the field order in ParsedWord is such that there's a fair amount of wasted pad space on 64-bit builds. I doubt we can get away with rearranging it in released branches; but maybe it's worth doing something about that in HEAD, to push out the point at which you hit the 1Gb limit. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="bound-lenwords-in-to_tsvector_byid.patch"; charset="us-ascii" Content-ID: <1056570.1695404930.2@sss.pgh.pa.us> Content-Description: bound-lenwords-in-to_tsvector_byid.patch diff --git a/src/backend/tsearch/to_tsany.c b/src/backend/tsearch/to_tsany.c index 3b6d41f9e8..fe39d6c4b9 100644 --- a/src/backend/tsearch/to_tsany.c +++ b/src/backend/tsearch/to_tsany.c @@ -252,6 +252,8 @@ to_tsvector_byid(PG_FUNCTION_ARGS) * number */ if (prs.lenwords < 2) prs.lenwords = 2; + else if (prs.lenwords > MaxAllocSize / sizeof(ParsedWord)) + prs.lenwords = MaxAllocSize / sizeof(ParsedWord); prs.curwords = 0; prs.pos = 0; prs.words = (ParsedWord *) palloc(sizeof(ParsedWord) * prs.lenwords); ------- =_aaaaaaaaaa0--