file...
>
> I think the reason this recurred is that, since upgrading to pg14, I no longer
> had your memleak patches applied. I'd forgotten about it, but was probably
> running a locally compiled postgres with your patches applied.
>
> I should've mentioned that this crash was asso
s associated with the message from the
original problem report:
|terminate called after throwing an instance of 'std::bad_alloc'
| what(): std::bad_alloc
The leak discussed on other threads seems fixed by your patches - I compiled
v14 and now running with no visible leaks sinc
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.
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
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),
> >
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
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
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;
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);
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
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
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
> > >
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
>
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
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
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:
> > > >
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,
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
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
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
ly, the filesystem wasn't large enough and the corefile is
> truncated.
Too bad.
> |[pryzbyj@database7 ~]$ sudo gzip -dc
> /var/log/postgresql/crash-postgresql-2020-09-30_194000.log.gz |head
> |[sudo] password for pryzbyj:
> |terminate called after throwing an instance of 'std::bad_al
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,
ete: wrote 35 buffers
(0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=3.523 s, sync=0.006
s, total=3.544 s; sync files=14, longest=0.002 s, average=0.000 s; distance=103
kB, estimate=4615 kB
This seemed familiar, and I found it had happened 18 months ago on a different
server:
|termina
28 matches
Mail list logo
