Nathan Bossart <nathandbossart@gmail.com> writes:
> I concur with Tom that this is most likely due to template1 not being
> marked as a template database in the source cluster. We could presumably
> hack pg_upgrade to deal with this for template1 and postgres databases
> (e.g., by preemptively setting datistemplate = f on the new cluster).
> Changes to template0 are likely harder to deal with. Since pg_dump uses it
> as the template for databases it creates, we'd have to wait until all other
> databases are restored before re-creating it. Plus, we'd probably have to
> first create a fresh template0 clone (with the source template0's encoding
> and locale settings) so that there was something to use as a template for
> template0. There might be other problems, and I'm not sure it's worth the
> effort, anyway.
Yeah. The logic about this is in pg_dump, actually: dumpDatabase()
decides whether or not to add "UPDATE ... SET datistemplate = false"
to the delQry. I was thinking about having it do that either if
the source DB has datistemplate or if its name is template1.
That would cover both (1) restoring a nonstandard set of databases
into the original installation with --clean, and (2) restoring a
nonstandard setup into a pristine installation. I don't think we
need to account for template0 because neither pg_dumpall nor
pg_upgrade will attempt to replace it.
However, first I'd like confirmation that this theory explains
the OP's problem.
regards, tom lane
