From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | btober(at)ct(dot)metrocast(dot)net |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_dumpall problem when roles have default schemas |
Date: | 2008-08-28 15:43:31 |
Message-ID: | 11748.1219938211@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
btober(at)ct(dot)metrocast(dot)net writes:
> Thus, when piping the output (from legacy host 192.168.2.2) to
> populate the newly initialized cluster, by way of running (on the new
> host 192.168.2.3)
> pg_dumpall -h 192.168.2.2|psql
> an error occurs in that first section when the script attempts to
> set a role-specific search path ... because the schema named in the
> search path hasn't been created yet.
Could we see a complete example?
Recent versions of the backend are not supposed to throw hard errors in
this situation, because of exactly that hazard. For instance:
regression=# create role joe;
CREATE ROLE
regression=# alter role joe set search_path to foo, bar;
NOTICE: schema "foo" does not exist
NOTICE: schema "bar" does not exist
ALTER ROLE
regression=#
which AFAICS is exactly what will happen while restoring a pg_dumpall
dump.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-08-28 15:48:00 | Re: Vaccuum best practice: cronjob or autovaccuum? |
Previous Message | Bill Moran | 2008-08-28 15:27:09 | Re: Vaccuum best practice: cronjob or autovaccuum? |