Re: WIP: Access method extendability

Hi, Heikki!

Thank you for summarizing. In general, I agree with your notes with
some exceptions.

On Mon, Nov 24, 2014 at 1:52 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com
> wrote:

> On 11/10/2014 10:30 PM, Alexander Korotkov wrote:
>
>> Don't allowing CREATE ACCESS METHOD command seems problematic for me. How
>> could it work with pg_upgrade? pg_dump wouldn't dump extra pg_am records.
>> So, pg_upgrade would break at creating operator classes on new cluster.
>> So,
>> I agree with dropping create am command only if we let pg_dump to dump
>> extra pg_am records...
>>
>
> pg_dump would dump the CREATE EXTENSION command, and the extension's
> installation script inserts the row to pg_am. pg_dump doesn't dump objects
> that are part of an extension, so that's how this would work with the
> CREATE ACCESS METHOD command, too.
>

In binary upgrade mode pg_dump have to guarantee that all database objects
will have same oids. That's why in binary upgrade mode pg_dump dumps
extension contents instead of just CREATE EXTENSION command.

> Backtracking a bit, to summarize the discussion so far:
>
> * It would be nice to have indexes that are not WAL-logged, but are
> automatically re-created after a crash. But it's a completely different and
> orthogonal feature, so there's no need to discuss that further in this
> thread.
>
> * If an extension is buggy, it can crash and corrupt the whole database.
> There isn't really anything we can do about that, and this patch doesn't
> make that any better or worse.
>
> * CREATE ACCESS METHOD command isn't worth it.
>

Taking into account my previous note, how can custom extensions survive
pg_upgrade without CREATE ACCESS METHOD command?

------
With best regards,
Alexander Korotkov.