Dean Rasheed writes:
> On 31 January 2010 16:03, Tom Lane 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);
> i
On 31 January 2010 16:03, Tom Lane wrote:
> Dean Rasheed writes:
>> Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be
>> freed otherwise lots of lists (one per row) will build up and not be freed
>> until the end of the query. This actually accounts for even more memory
>>
Dean Rasheed writes:
> Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be
> freed otherwise lots of lists (one per row) will build up and not be freed
> until the end of the query. This actually accounts for even more memory
> than the after-trigger event queue. Patch attache
Oops, my fault. The list returned by ExecInsertIndexTuples() needs to be
freed otherwise lots of lists (one per row) will build up and not be freed
until the end of the query. This actually accounts for even more memory
than the after-trigger event queue. Patch attached.
Of course the after-trigge
