Re: WIP: Access method extendability

Hi,

On 2014-10-15 16:08:38 +0400, Alexander Korotkov wrote:
> Postgres was initially designed to support access methods extendability.
> This extendability lives to present day. However, this is mostly internal
> in-core extendability. One can quite easily add new access method into
> PostgreSQL core. But if one try to implement access method as external
> module, he will be faced with following difficulties:
>
> 1. Need to directly insert into pg_am, because of no "CREATE ACCESS
> METHOD" command. And no support of dependencies between am and opclasses
> etc.
> 2. Module can't define xlog records. So, new am would be not WAL-logged.
>
> The first problem is purely mechanical. Nothing prevents us to implement
> "CREATE ACCESS METHOD" and "DROP ACCESS METHOD" commands and support all
> required dependencies.
>
> Problem of WAL is a bit more complex. According to previous discussions, we
> don't want to let extensions declare their own xlog records. If we let them
> then recovery process will depend on extensions. That is much violates
> reliability. Solution is to implement some generic xlog record which is
> able to represent difference between blocks in some general manner.

I think this is a somewhat elegant way to attack this problem. But I'm
not so sure it's actually sufficient. Consider e.g. how to deal with hot
standby conflicts? How would you transport the knowledge that there's a
xid conflict to the client?

I guess my question essentially is whether it's actually sufficient for
real world AMs.

The other thing I'm not sure about is that I'm unconvinced that we
really want external AMs...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services