There's no leak after running for ~5 weeks.
$ ps -O lstart,vsize,rss 17930
PID STARTEDVSZ RSS S TTY TIME COMMAND
17930 Tue Nov 30 15:35:26 2021 1019464 117424 S ? 7-04:54:03 postgres:
telsasoft ts 192.168.122.13(57640) idle
Unless you suggest otherwise , I'
On Wed, Nov 10, 2021 at 09:56:44AM -0600, Justin Pryzby wrote:
> Thread starting here:
> https://www.postgresql.org/message-id/20201001021609.GC8476%40telsasoft.com
>
> On Fri, Dec 18, 2020 at 05:56:07PM -0600, Justin Pryzby wrote:
> > I'm 99% sure the "bad_alloc" is from LLVM. It happened multip
Thread starting here:
https://www.postgresql.org/message-id/20201001021609.GC8476%40telsasoft.com
On Fri, Dec 18, 2020 at 05:56:07PM -0600, Justin Pryzby wrote:
> I'm 99% sure the "bad_alloc" is from LLVM. It happened multiple times on
> different servers (running a similar report) after setting
There's a memory leak affecting JIT expressions, even when inlining,
optimization, and tuple deforming are disabled.
The server that got OOM after installing PG13.3 (because your patch wasn't
applied) still gets OOM even with inline_above_cost=-1, optimize_above_cost=-1,
and deforming=off.
Actual
I think you were thinking that the jit_inline_above_cost=0 for queries within
plpgsql functions is pathological and not a useful test case, since the
function can be called an arbitrarily large number of times, but the jit
context can't be reset mid-query due to nonzero reference count.
I think yo
On Tue, Apr 20, 2021 at 06:16:28PM -0700, Andres Freund wrote:
> On 2021-04-20 20:03:13 -0500, Justin Pryzby wrote:
> > That's a query over a 2 day period (midnight to midnight+2), so it's not
> > hard
> > for me to believe it sometimes exceeds 100k cost units
> > (jit_inline_above_cost),
> > dep
Hi,
On 2021-04-20 20:03:13 -0500, Justin Pryzby wrote:
> That's a query over a 2 day period (midnight to midnight+2), so it's not hard
> for me to believe it sometimes exceeds 100k cost units
> (jit_inline_above_cost),
> depending on where we are in that interval, and on planner statistics. It
>
On Tue, Apr 20, 2021 at 05:20:56PM -0700, Andres Freund wrote:
> On 2021-04-20 00:58:21 -0500, Justin Pryzby wrote:
> > On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote:
> > > I don't know if this is related to the other issues, but this seems leaky.
> >
> > And it explains how the co
Hi,
On 2021-04-20 00:58:21 -0500, Justin Pryzby wrote:
> On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote:
> > I don't know if this is related to the other issues, but this seems leaky.
>
> And it explains how the context use counter can exceed its threshold.
>
> create or replace f
On Tue, Apr 20, 2021 at 12:38:26AM -0500, Justin Pryzby wrote:
> I don't know if this is related to the other issues, but this seems leaky.
And it explains how the context use counter can exceed its threshold.
create or replace function fn() returns void language plpgsql as $$ declare rec
int; b
I don't know if this is related to the other issues, but this seems leaky.
create or replace function fn() returns void language plpgsql as $$ declare rec
int; begin SELECT relpages INTO rec FROM pg_class LIMIT 1; end $$;
explain analyze
SELECT fn()
FROM generate_series(1,999);
PGOPTIONS='-cclie
On Mon, Apr 19, 2021 at 09:41:30AM -0700, Andres Freund wrote:
> On 2021-04-17 19:13:24 -0500, Justin Pryzby wrote:
> > I'm now realizing that that's RAM use for a single query, not from
> > continuous
> > leaks across multiple queries.
>
> What's the memory usage with inlining disabled, and what
Hi,
On 2021-04-17 19:13:24 -0500, Justin Pryzby wrote:
> I'm now realizing that that's RAM use for a single query, not from continuous
> leaks across multiple queries.
What's the memory usage with inlining disabled, and whats the usage
without jit?
> This is still true with the patch even if I
On Fri, Apr 16, 2021 at 10:18:37PM -0500, Justin Pryzby wrote:
> On Fri, Apr 16, 2021 at 09:48:54PM -0500, Justin Pryzby wrote:
> > On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > > > I'd be happy to run wi
Hi,
On Fri, Apr 16, 2021, at 20:18, Justin Pryzby wrote:
> On Fri, Apr 16, 2021 at 09:48:54PM -0500, Justin Pryzby wrote:
> > On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > > > I'd be happy to run with a
On Fri, Apr 16, 2021 at 09:48:54PM -0500, Justin Pryzby wrote:
> On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > > I'd be happy to run with a prototype fix for the leak to see if the other
> > > issue
> > > does
On Fri, Apr 16, 2021 at 07:17:55PM -0700, Andres Freund wrote:
> Hi,
>
> On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> > I'd be happy to run with a prototype fix for the leak to see if the other
> > issue
> > does (not) recur.
>
> I just posted a prototype fix to
> https://www.postgresql
Hi,
On 2020-12-18 17:56:07 -0600, Justin Pryzby wrote:
> I'd be happy to run with a prototype fix for the leak to see if the other
> issue
> does (not) recur.
I just posted a prototype fix to
https://www.postgresql.org/message-id/20210417021602.7dilihkdc7oblrf7%40alap3.anarazel.de
(just because
I'm re-raising this issue (since I needed to track down why I'd reflexively
saved a 512g backup of the filesystem where this first happened).
I'm 99% sure the "bad_alloc" is from LLVM. It happened multiple times on
different servers (running a similar report) after setting jit=on during pg13
upgr
Hi,
Sorry for the second send of this email, but somehow I managed to mangle
the headers in the last version I sent.
On 2020-10-03 19:01:27 -0700, Andres Freund wrote:
> On 2020-10-03 18:30:46 -0500, Justin Pryzby wrote:
> > On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> > > > I
Hi,
On 2020-10-03 19:01:27 -0700, Andres Freund wrote:
> On 2020-10-03 18:30:46 -0500, Justin Pryzby wrote:
> > On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> > > > I was able to make a small, apparent leak like so. This applies to
> > > > postgis3.0/postgres12/LLVM5/centos7, an
Hi,
On 2020-10-03 18:30:46 -0500, Justin Pryzby wrote:
> On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> > > I was able to make a small, apparent leak like so. This applies to
> > > postgis3.0/postgres12/LLVM5/centos7, and
> > > postgis3.1alpha/postgres13/LLVM9/centos8.
> > >
> >
On Sat, Oct 03, 2020 at 04:01:49PM -0700, Andres Freund wrote:
> The below turned out to be somewhat obsoleted by what you wrote below,
> which I unfortunately hadn't yet read - but I think it's still good
> information, so I'm not gonna delete it:
Right, I understand that RES RAM might includes s
Hi,
On 2020-10-03 17:02:36 -0500, Justin Pryzby wrote:
> We didn't use JIT with v12, but I've been setting jit=on along with v13
> upgrades, so I was trying to convince myself that there's a change in v13, and
> not just our config..
>
> I've seen repeated OOMs on a small number of reports. It lo
On Wed, Sep 30, 2020 at 09:16:09PM -0500, Justin Pryzby wrote:
> Our DBs use postgis, and today's crash JOINs to the table with geometry
> columns, but does not use them at all.
I'm wrong here - it does return the geometry columns.
We didn't use JIT with v12, but I've been setting jit=on along wi
Hi,
On 2020-09-30 21:16:10 -0500, Justin Pryzby wrote:
> Sep 30 19:40:08 database7 abrt-hook-ccpp: Process 17905 (postgres) of user 26
> killed by SIGABRT - dumping core
> Core was generated by `postgres: telsasoft ts 192.168.122.11(34608) SELECT
> '.
>
> Unfortunately, the filesystem wasn't
Justin Pryzby writes:
> A VM crashed which is now running PG13.0 on centos7:
> Sep 30 19:40:08 database7 abrt-hook-ccpp: Process 17905 (postgres) of user 26
> killed by SIGABRT - dumping core
> Core was generated by `postgres: telsasoft ts 192.168.122.11(34608) SELECT
> '.
> Unfortunately, t
27 matches
Mail list logo
