lookup_rowtype_tupdesc considered harmful
От | Tom Lane |
---|---|
Тема | lookup_rowtype_tupdesc considered harmful |
Дата | |
Msg-id | 24471.1136768659@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: lookup_rowtype_tupdesc considered harmful
|
Список | pgsql-hackers |
I've been running the regression tests with the sinval-reset stress testing program I posted yesterday: http://archives.postgresql.org/pgsql-hackers/2006-01/msg00244.php I've seen several crashes caused by using a tuple descriptor obtained from lookup_rowtype_tupdesc() after the descriptor has been recycled due to cache flushes. On reflection I think that lookup_rowtype_tupdesc is simply misdesigned. We can't have it handing back a pointer to a data structure of unspecified lifetime. One possibility is to give it an API comparable to the syscache lookup functions, ie you get a reference-counted pointer that you have to explicitly release when done with it. This would also presumably require extending the ResourceOwner mechanism to track these reference counts. A simpler alternative is just to make every caller copy the passed-back tupdesc immediately if it's going to do more than the most trivial work with it; or even put the copying step right into lookup_rowtype_tupdesc to make sure no one can omit it. Here we'd be paying palloc and data copying overhead to keep the code simple. However, it's arguable that none of the uses of lookup_rowtype_tupdesc are performance-critical enough to justify adding a lot of infrastructure to avoid this. One big strike against the reference-count approach is that it'd be difficult to back-patch such a solution into existing branches, since it would amount to an incompatible API change. If there are any add-on modules out there that use lookup_rowtype_tupdesc, they'd start failing because of not releasing the pointer. Any opinions what to do? regards, tom lane
В списке pgsql-hackers по дате отправления: