Re: select 'x' ~ repeat('x*y*z*', 1000); - Mailing list pgsql-hackers

From Tom Lane
Subject Re: select 'x' ~ repeat('x*y*z*', 1000);
Date
Msg-id 484514.1618896881@sss.pgh.pa.us
Whole thread Raw
In response to select 'x' ~ repeat('x*y*z*', 1000);  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> Just an observation: on REL_13_STABLE, $SUBJECT maps in ~170MB of
> memory, and on master it's ~204MB.  A backend running that was just
> nuked by the kernel due to lack of swap space on my tiny buildfarm
> animal elver (a VM with 1GB RAM, 2GB swap, not doing much else).

Yeah, that's not terribly surprising.  Note that the point of that
test case is to fail: it's supposed to verify that we apply the
REG_MAX_COMPILE_SPACE limit and error out before hitting a kernel
OOM condition.  When I redid regex memory allocation in 0fc1af174,
there was a question of how to map the old complexity limit to the
new one.  I went with

 #define REG_MAX_COMPILE_SPACE  \
-   (100000 * sizeof(struct state) + 100000 * sizeof(struct arcbatch))
+   (500000 * (sizeof(struct state) + 4 * sizeof(struct arc)))
 #endif

knowing that that was a bit of a scale-up of the limit, but intending
that we'd not fail on any case that worked before.  We could knock
down the 500000 multiplier a little, but I'm afraid we'd lose the
it-still-works property, because the edge cases are a little different
for the new code than the old.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: 2 questions about volatile attribute of pg_proc.
Next
From: Justin Pryzby
Date:
Subject: Re: terminate called after throwing an instance of 'std::bad_alloc'