From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: select 'x' ~ repeat('x*y*z*', 1000); |
Date: | 2021-04-20 05:34:41 |
Message-ID: | 484514.1618896881@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-04-20 05:38:26 | Re: terminate called after throwing an instance of 'std::bad_alloc' |
Previous Message | Andy Fan | 2021-04-20 05:32:05 | Re: 2 questions about volatile attribute of pg_proc. |