Re: BUG #4204: COPY to table with FK has memory leak

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #4204: COPY to table with FK has memory leak
Date: 2008-05-28 20:28:27
Message-ID: 5183.1212006507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> This is expected to take lots of memory because each row-requiring-check
>> generates an entry in the pending trigger event list.

> Hm, it occurs to me that we could still do a join against the pending event
> trigger list... I wonder how feasible it would be to store the pending trigger
> event list in a temporary table instead of in ram.

We could make that list spill to disk, but the problem remains that
verifying the rows one at a time will take forever.

The idea that's been kicked around occasionally is that once you get
past N pending events, throw them all away and instead queue a single
operation to do a bulk verify (just like initial establishment of the
FK constraint). I'm not sure how to do the queue management for this
though.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Gregory Stark 2008-05-28 20:47:35 Re: BUG #4204: COPY to table with FK has memory leak
Previous Message Gregory Stark 2008-05-28 18:22:36 Re: BUG #4204: COPY to table with FK has memory leak

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-05-28 20:32:06 Re: Avoiding second heap scan in VACUUM
Previous Message Pavel Stehule 2008-05-28 20:13:31 Re: Packages in oracle Style