> Another testimonial to the stability of Postgres :)
> We may be arguing semantics
> here but I would consider dump/restore an admin function. How do you
> handle a
> client restoring a database currently?
Database is 8.0 compliant.
In this case 8.4 pg_dump/pg_restore is used to dump and restore with any
same version 8 of server witthout issues.
This was broken in 9:
Postgres 9 emits invalid "create procedural language plpgsql" command which
does not work in any other version.
How to fix this without distributing two copies of pg_dump/pg_restore ?
Is it reasonable to create database and plpgsql language manually before
running pg_restore ? In this case invalid "create procedural language
plpgsql" issued by pg_restore gets ignored and maybe restore succeeds?
> I could see a client connecting to one
> of the system dbs and doing a DROP DATABASE.
> From your earlier messages the
> implication was that you used pg_restore to repopulate the db. My question
> then
> is how do the clients make sure that they are not doing this on an active
> database
> and keep it from going active during the process?
Applicaton asks for new database name and verifies that this does not exist
before executing
pg_restore.
Another requirement is to clone existing database in server with data. I
posted question about it and it seems that PostgreSql does not have any
capability to do this in server side in plpgsql fast.
So we need to use slow and unsafe dump/restore over internet for this also.
Andrus.
