Sure. I will try that. On Tue, Feb 23, 2021 at 4:42 PM Adrian Klaver <adrian.kla...@aklaver.com> wrote:
> On 2/23/21 4:25 PM, Santosh Udupi wrote: > > Yes, this is what we have been doing now:- Backup using pg_dump, create > > the new database at the destination, manually create the tables which > > give problems, and then do the pg_restore. Another solution for us is to > > Well that introduces another error, where the restore trips on the > existing table(s). By the way this is the first time you mentioned > multiple tables. Do they share similar structure? In any case you should > not have to do this and in the spirit of identifying the problem and > fixing it, what happens if you do: > > 1) Dump locally > > 2) Restore locally, without creating the tables ahead. > > 3) Examine and report back here the table(s) schema(and sample data) > after the fresh restore. > > 4) Drop the table(s) and create from script and populate. Report on > whether they work. > > > backup using pg_dump that comes with pgAdmin (Windows), rsync it to the > > destination server and then do the pg_restore on the server. > > > > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
