TupleDesc refcounting
От | Neil Conway |
---|---|
Тема | TupleDesc refcounting |
Дата | |
Msg-id | 1136932864.26329.17.camel@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: TupleDesc refcounting
|
Список | pgsql-patches |
Attached is a WIP patch that adds reference counting for TupleDescs. Two issues that I ran into while implementing it: (1) How should the lifetime of a TupleDesc be managed? The existing ResourceOwner stuff seems to assume that it is managing "per-query" resources. A TupleDesc will often live beyond the lifetime of a single transaction, and might even be created before transactions can be started (e.g. formrdesc() in relcache.c, when we're creating relcache entries for nailed-in-cache relations early in InitPostgres()). In current sources, the lifetime of a TupleDesc is the lifetime of the memory context in which it is allocated (and/or whenever FreeTupleDesc() is invoked). We could imitate that behavior by optionally linking a ResourceOwner with each MemoryContext, and releasing the ResourceOwner when the MemoryContext is reset or deleted. However, I'm not sure that that's the right approach... (2) The existing ResourceOwner users issue a warning if the resource they are managing is not explicitly released before a transaction successfully commits (so they elog(WARNING)). I don't see the need to be that strict for TupleDescs -- as we do with palloc() without a matching pfree(), I think it should be okay to just silently clean up "leaked" TupleDescs when releasing a ResourceOwner. Thoughts? -Neil
Вложения
В списке pgsql-patches по дате отправления: