Re: select 'x' ~ repeat('x*y*z*', 1000);
От | Tom Lane |
---|---|
Тема | Re: select 'x' ~ repeat('x*y*z*', 1000); |
Дата | |
Msg-id | 484514.1618896881@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | select 'x' ~ repeat('x*y*z*', 1000); (Thomas Munro <thomas.munro@gmail.com>) |
Список | 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 по дате отправления: