Thread: system objects

From: pgadmin-support-owner@postgresql.org
[mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Dagoberto
Torres
Sent: 19 February 2005 23:06
To: pgadmin-support@postgresql.org
Subject: [pgadmin-support] system objects
>
> Hello
>
> I'm using pgAdmin III 1.2.0 compiled november 29 2004.
> Some time ago I decided to click the display systmem objects
> option, since then I can't switch it off (even it says it's
> off it really keeps on internally).
Eh? What do you mean 'it really keeps on internally?' pgAdmin actually
stores the schema data on each treeview node - if the node isn't there
because system objects are turned off, then the data isn't there either.
> The main problem is that fails when restoring a backup made
> with the same pgAdmin because of a conflict with one of those
> system objects.
The system objects option does not affect backups or restores in any way
at all. Perhaps if you supplied the error message you are seeing we
might be more able to help
Regards, Dave

---

From: Dagoberto Torres [mailto:support@info-plus.org]
Sent: 21 February 2005 21:49
To: Dave Page
Subject: RE: [pgadmin-support] system objects

Hello, Dave here are the error lines: ` pg_restore: restoring data for table "pg_ts_cfg" pg_restore: ERROR:  duplicate key violates unique constraint "pg_ts_cfg_pkey" CONTEXT:  COPY pg_ts_cfg, line 1: "17961 default default C" pg_restore: [archiver (db)] error returned by PQendcopy pg_restore: *** aborted because of error   Process returned exit code 1.   All the time I see things I've never created as domain earth, view pg_logdir_ls, function _get_parser_from_curcfg()   and stuff like that.  I think it has something to do about the restore problem.  By the way I see pg_ts_cfg, pg_ts_cfgmap, pg_ts_dict, pg_ts_parses in the tables section too.   Those are PostgreSQL contrib modules - they will not be recognised as system objects by pgAdmin because they are not part of the core server. Any of those may be safely dropped (if they are *not* in the pg_catalog schema) , however, pgAdmin does use pg_file_*, pg_dir_ls, pg_reload_conf, pg_postmaster_starttime, pg_logdir_ls (view and function) so you might want to keep those.   The one you are seeing the error with, is part of tsearch2. Because it's failing on a primary key constraint, my guess is that you are restoring to a database that already has that table and data in it. This would be the case if you installed tsearch2 into template1, and then created your blank database from that (quite possible, if you are running a pgInstaller installation on Windows).   To fix this, when you create the new database to restore into, select 'template0' as the template database. This will ensure that it is completely empty, and should allow the full restore of all the contrib modules to work as expected.   Regards, Dave.