On 20/08/10 15:45, Greg Stark wrote:
> On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas<robertmhaas@gmail.com> wrote:
>> A related, interesting question is whether there's any purpose to the
>> smgr layer at all. Would we accept a patch that implemented an
>> alternative smgr layer, perhaps on a per-tablespace basis?
>
> I definitely want to keep it.
>
> I think we could usefully do an application-level raid implementation.
> It would be useful for people running on machines where they don't
> have administrative access on the machine. In particular I'm picturing
> shared cluster machines that run other jobs and can't be reconfigured
> specifically for the database. Adding per-tablespace behaviour would
> make the argument a lot stronger too since it's not so easy to set up
> different stripe sizes per table if you're using OS level raid.
>
> I also have various crazy plans to experiment with network-based
> storage and had intended to use smgr to do so. At google we have a
> bunch of different storage technologies and they're all
> application-level network services. You can always implement a fuse
> module that calls back up to a daemon which acts as the client but
> that doesn't make me feel any happier about it.
I think you would be better off implementing that somewhere in md.c, or
even file.c. The smgr layer has been dead for such a long time that it
would take a significant amount of work to make it usable again. The
whole infrastructure to handle fsyncs() at checkpoints, for example, is
in md.c, so you'd need to rewrite all that.
> And I know EDB has their infinicache thing using memcached -- I don't
> recall if it uses the smgr layer but it would certainly be a natural
> place to hook it in.
FWIW, it doesn't. It's in bufmgr, it needs some co-operation from the
buffer cache.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com