| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Failure while inserting parent tuple to B-tree is not fun |
| Date: | 2014-02-05 23:54:33 |
| Message-ID: | CAM3SWZS-L_r2PFo1e5OwL4SYrVuha6+DrxYwipW=nNsgTrrYYA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 23, 2014 at 1:36 PM, Peter Geoghegan <pg(at)heroku(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marti Raudsepp | 2014-02-05 23:58:51 | Re: PoC: Partial sort |
| Previous Message | Tom Lane | 2014-02-05 23:41:08 | Re: mvcc catalo gsnapshots and TopTransactionContext |