every of that queries led to a server crash at a number of
savepoints in the range from 174,400 to 174,700.
With your patches applied, the savepoint counter goes well beyond these
values, I settled on an amount of approximately 300,000 savepoints.
Your patches look good to me.
Best regards,
Egor Chindyaskin
Postgres Professional: http://postgrespro.com/
Hello! In continuation of the topic I would like to suggest solution.
This patch adds several checks to the vulnerable functions above.diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index d85e313908..102d0e1574 100644
--- a/src/backend/access/transam/xact.c
+++
03.01.2023 22:45, Sascha Kuhl writes:
Great work. Max Stack depth is memory dependent? Processor dependent?
Hello! These situations are not specific to the x86_64 architecture, but
also manifest themselves, for example, on aarch64 architecture.
For example this query, ran on aarch64, (n=10
Hello! In continuation of the topic, I, under the leadership of
Alexander Lakhin, prepared patches that fix these problems.
We decided that these checks would be enough and put them in the places
we saw fit.diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c
index f
24.08.2022 20:58, Tom Lane writes:
Nice work! I wonder if you can make the regex crashes reachable by
reducing the value of max_stack_depth enough that it's hit before
reaching the "regular expression is too complex" limit.
regards, tom lane
Hello everyone! It's been a w
