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 <hlinnakan...@vmware.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.
