You may want to zero in on the problem by performing database dumps
(using pg_dump and the various options accordingly) then restore on the
failing installation using the psql command.
Maybe (I am guessing here, you haven't elaborated on "crashes") you may
be issuing insert statements (in the pgAdmin generated file) on
previously populated tables. Or perhaps you are inserting (or updating)
dependent (child) tables without populating the parent table while
having the referential integrity constraints present. pg_dump has an
elegant way of avoiding such pitfalls.
Allan.
On Tue, Apr 28, 2009 at 5:43 PM, Christine Penner
<christine@xxxxxxxxxxxxxxxxxxxxx> wrote:
> We are in the process of converting our application to use Postgres.
We have
> about 5 computers in the office. We frequently create a database on one
> computer and then transfer it to the other computers as needed. We are
> currently doing this all through pgAdmin.
>
> We backup a data base using the default (Compress) format. We select the
> Insert Commands option.
> We use restore on the other computers to load the database. We select
the no
> owner option.
>
> Quite often this works fine but we have had a lot of crashes.
Sometimes we
> are unable to load a database. Sometimes we load over an existing
database
> but not always. Doesn't seem to make a difference.
>
> The big problem with the crashes is the only way to be able to use
Postgres
> at that point is to restart the whole computer.
>
> We are all using 8.3.4 on Windows XP
>
> Christine Penner
> Ingenious Software
> 250-352-9495
> christine@xxxxxxxxxxxxxxxxxxxxx
>
> --
> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
