Re: Failure while inserting parent tuple to B-tree is not fun
От | Peter Geoghegan |
---|---|
Тема | Re: Failure while inserting parent tuple to B-tree is not fun |
Дата | |
Msg-id | CAM3SWZS-L_r2PFo1e5OwL4SYrVuha6+DrxYwipW=nNsgTrrYYA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Failure while inserting parent tuple to B-tree is not fun (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Failure while inserting parent tuple to B-tree is not
fun
|
Список | pgsql-hackers |
On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan <pg@heroku.com> wrote: > So while post-recovery callbacks no longer exist for any > rmgr-managed-resource, 100% of remaining startup and cleanup callbacks > concern the simple management of memory of AM-specific recovery > contexts (for GiST, GiN and SP-GiST). I have to wonder if there isn't > a better abstraction than that, such as a generic recovery memory > context, allowing you to retire all 3 callbacks. I mean, StartupXLOG() > just calls those callbacks for each resource at exactly the same time > anyway, just as it initializes resource managers in precisely the same > manner earlier on. Plus if you look at what those AM-local memory > management routines do, it all seems very simple. What are your thoughts on this, as someone that has a broader perspective here? Are you inclined to keep the startup and cleanup callbacks in anticipation of a day when that degree of generality is useful? That would be pretty well-precedented of course, but I would like to hear your opinion. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: