Skip site navigation (1) Skip section navigation (2)

Re: Memory leak in deferrable index constraints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Memory leak in deferrable index constraints
Date: 2010-01-31 18:26:07
Message-ID: 13724.1264962367@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com> writes:
> On 31 January 2010 16:03, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It seems a bit unlikely that this would be the largest memory leak in
>> that area. Can you show a test case that demonstrates this is worth
>> worrying about?

> create table foo(a int unique deferrable initially deferred);
> insert into foo (select * from generate_series(1, 10000000));
> begin;
> update foo set a=a+1;
> set constraints all immediate;
> commit;

Thanks.  I had forgotten all the work we put into minimizing the size of
the deferred trigger queue.  In this example it's only 16 bytes per
entry, whereas a 1-element List is going to involve 16 bytes for the
header, 8 bytes for the cell, plus two palloc item overheads --- and
double all that on a 64-bit machine.  So yeah, this is a significant
leak.  Patch applied.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-01-31 19:00:08
Subject: Re: Hot Standby and VACUUM FULL
Previous:From: Magnus HaganderDate: 2010-01-31 17:51:10
Subject: Re: mailing list archiver chewing patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group