Re: dblink() cursor error/issue (TopMemoryContext) - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: dblink() cursor error/issue (TopMemoryContext)
Date
Msg-id 20080614223454.GE8519@alvh.no-ip.org
Whole thread Raw
In response to Re: dblink() cursor error/issue (TopMemoryContext)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: dblink() cursor error/issue (TopMemoryContext)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:

> (I wonder whether we can't improve on that, at least for the case of a
> non-deferred after trigger, which'd have already been fired before we
> exit the subtransaction.  The trick is how to know that there's nothing
> useful left in the subtransaction's per-transaction memory context ...)

I think this would require us to be smarter about what pfree's are
leaving the context empty.  Whether this requires us to troll the
freelist and aggregate contiguous elements, or something even more
complex, I don't know.  The fact that this adds a bit more complexity to
pfree() worries me.

Perhaps we could have something like MemoryContextDefrag that we would
invoke at subtransaction end.  If the context is truly empty it can
leave it in the initial empty state, which I think is enough for the
subxact code to know that it can remove it.

Unless I'm misunderstanding the issue completely.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: why sequential scan is used on indexed column ???
Next
From: Tom Lane
Date:
Subject: Re: dblink() cursor error/issue (TopMemoryContext)