From: | Duncan Sands <duncan(dot)sands(at)deepbluecap(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Unlimited memory consumption with long-lived connection |
Date: | 2023-02-22 17:10:25 |
Message-ID: | 5989ffab-a824-e029-3f09-fa578593023a@deepbluecap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Justin,
>>> PS: The testcase was reduced from a script that kept a connection open for a
>>> long time in order to LISTEN, and would execute a query using the same
>>> connection every time there was a notification on the channel. It consumed ever
>>> more memory to the point of crashing the postgresql server. Changing the script
>>> to perform the query using a new short-lived connection was an effective workaround.
>
> It sounds like the same as the issue here:
> https://wiki.postgresql.org/wiki/PostgreSQL_13_Open_Items
I agree that it is likely the same issue.
> There are patches proposed here, which fixed the issue for me.
> But I've always been suspicious that there may be a 2nd, undiagnosed
> issue lurking behind this one...
> https://www.postgresql.org/message-id/20210417021602.7dilihkdc7oblrf7%40alap3.anarazel.de
Thanks. Since those patches are just a workaround, and I already worked around
it, I don't plan to give them a whirl. On the other hand, if Andres ever gets
round to implementing approach (1) from
https://www.postgresql.org/message-id/20210417021602.7dilihkdc7oblrf7@alap3.anarazel.de
then I'd be happy to give it a whirl. I'm rusty now but I used to be quite
expert in LLVM, so I might even be able to do some patch review.
Best wishes, Duncan.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-02-22 17:15:51 | Re: pg_dump: error |
Previous Message | David G. Johnston | 2023-02-22 16:44:55 | Re: pg_dump: error |