On Thu, Feb 10, 2022 at 2:35 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > I've rechecked that the now patched code branch is covered by
> > regression tests. I think the memory leak issue is independent of the
> > computational errors we've observed.
> > So, I'm going to push and backpatc
Alexander Korotkov writes:
> I've rechecked that the now patched code branch is covered by
> regression tests. I think the memory leak issue is independent of the
> computational errors we've observed.
> So, I'm going to push and backpatch this if no objections.
+1. We should work on the roundo
On Thu, Feb 10, 2022 at 1:19 AM Aliaksandr Kalenik wrote:
> On Mon, Feb 7, 2022 at 11:20 PM Alexander Korotkov
> wrote:
> > Regarding the memory leak, could you add a corresponding regression
> > test to the patch (probably similar to Tom's query upthread)?
>
> Yes, added similar to Tom's query
On Mon, Feb 7, 2022 at 11:20 PM Alexander Korotkov wrote:
> Regarding the memory leak, could you add a corresponding regression
> test to the patch (probably similar to Tom's query upthread)?
Yes, added similar to Tom's query but with polygons instead of circles.
0002-nodeindexscan_with_reorder
Hi!
On Mon, Feb 7, 2022 at 11:42 AM Aliaksandr Kalenik wrote:
> Thanks for your review!
>
> On Sun, Jan 30, 2022 at 7:24 PM Tom Lane wrote:
> > Actually, that code has got worse problems than that. I tried to improve
> > our regression tests to exercise that code path, as attached. What I got
Thanks for your review!
On Sun, Jan 30, 2022 at 7:24 PM Tom Lane wrote:
> Actually, that code has got worse problems than that. I tried to improve
> our regression tests to exercise that code path, as attached. What I got
> was
>
> +SELECT point(x,x), (SELECT circle_center(f1) FROM gcircle_tbl
Aliaksandr Kalenik writes:
> I was investigating a leak reported in the PostGIS issues tracker [1] which
> led me to the Postgres side where the problem really is. The leak is
> reproducible with query from original ticket [1]:
> ...
> The leak is only noticeable when index scan with reorder happe
Aliaksandr Kalenik writes:
> The leak is only noticeable when index scan with reorder happens as part of
> subquery plan which is explained by the fact that heap tuples cloned in
> reorderqueue_push are not freed during flush of reorder queue in
> ExecReScanIndex.
Hmm ... I see from the code cove
Hey!
I was investigating a leak reported in the PostGIS issues tracker [1] which
led me to the Postgres side where the problem really is. The leak is
reproducible with query from original ticket [1]:
WITH latitudes AS (
SELECT generate_series AS latitude
FROM generate_series(-90,
