Re: select 'x' ~ repeat('x*y*z*', 1000);

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

In response to

Browse pgsql-hackers by date

  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.