Обсуждение: 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). 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. Any advice really appreciated. | |||
![Add FUN to your email - CLICK HERE!](http://www2.incredimail.com/contents/stamps/imstp_emo_en.gif)
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, Davehere 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 errorProcess 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.