| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | wheel <wheel(at)wheel(dot)not>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Restore database from files (not dump files)? |
| Date: | 2006-12-12 17:25:29 |
| Message-ID: | 200612121725.kBCHPTi25304@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tom Lane wrote:
> wheel <wheel(at)wheel(dot)not> writes:
> > I guess the reason is that the pg system database etc are lodged in the
> > hive under \base\, and the system db contains the metadata about the db
> > to be restored?
>
> No, the reason why selective restore doesn't work is that all tables in
> a database cluster depend on the same commit log (pg_clog) to determine
> which rows are valid and which are not. What you were trying to do is
> described in the manual (with a warning not to do it) under
> backup/restore procedures:
> http://www.postgresql.org/docs/8.2/static/backup-file.html
>
> Also, if you would like to know more about the physical layout of the
> database contents, it's described here:
> http://www.postgresql.org/docs/8.2/static/storage.html
This is the contents of /data:
PG_VERSION pg_clog/ pg_multixact/
pg_twophase/ postmaster.opts base/
pg_hba.conf pg_subtrans/ pg_xlog/
postmaster.pid global/ pg_ident.conf
pg_tblspc/ postgresql.conf
None of these are optional for restoring a database. They are all
interconected.
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul Silveira | 2006-12-12 17:28:32 | Re: shell script to populate array values |
| Previous Message | Tom Lane | 2006-12-12 17:25:22 | Re: date comparisons |