From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lots of memory allocated when reassigning Large Objects |
Date: | 2021-11-29 21:33:49 |
Message-ID: | CAECtzeV7GdYdszYLYaZM0GYL5brAqduV=fY6-n8yp_DxQs8L6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le lun. 29 nov. 2021 à 22:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> > Le lun. 29 nov. 2021 à 20:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
> >> [ looks closer ... ] Ah, that patch is a bit buggy: it fails to do the
> >> right thing in the cases where the loop does a "continue". The attached
> >> revision seems to behave properly.
>
> > I've tried your patch with my test case. It still uses a lot of memory.
> > Actually even more.
>
> Hmm ... I tried it with your test case, and I see the backend completing
> the query without going beyond 190MB used (which is mostly shared memory).
> Without the patch it blows past that point very quickly indeed.
>
> I'm checking it in HEAD though; perhaps there's something else wrong
> in the back branches?
>
>
That's also what I was thinking. I was only trying with v14. I just checked
with v15devel, and your patch works alright. So there must be something
else with back branches.
--
Guillaume.
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2021-11-29 21:37:30 | Re: improve CREATE EXTENSION error message |
Previous Message | Bossart, Nathan | 2021-11-29 21:33:21 | Re: improve CREATE EXTENSION error message |