pg_dump is a utility for saving a PostgreSQL database into a script or an
archive file. The script files are in plain-text format and contain the SQL
commands required to reconstruct the database to the state it was in
at the time it was saved.
"At the time it was saved" What is the m
Yes Database size is going to grow very large over time. The situation is
going to be like this that ther is one central server where n nr of
databases are there.
I want one of these databases to be restored to the Other database Server.
What i have found so far implies tht the whole of database se
Not sure, but i think WAL based incremental backup is for the whole database
cluster, and not for an specific database, so don't think this is going to
work for you. Is yoor database too large? If not, you could stick to the old
fashioned pg_dump output.
On Wednesday 17 January 2007 10:23, Shoa
I only want one of many databases to be restored to the other server
incrementally.
Is this possible?
If yes, Wht are the steps??
Regards,
Yogvinder Singh,
Software Engineer, E-WorkStyle Group,
Newgen Software Technologies Ltd.
D-152, Okhla Phase - 1
Tel no 26815467 Ext 143
- Original Messag
I apologize; I had intended to reply-all, and simply missed the mark somehow.
Also, thank you for the link to the documentation; it was clear enough that I
was able to get what I needed done...at least as far as I can tell, since it's
not finished yet.
Thank you very much for your g
On Wed, 17 Jan 2007, Ray Stell wrote:
On Wed, Jan 17, 2007 at 01:18:06PM -0800, Jeff Frost wrote:
On Wed, 17 Jan 2007, Ray Stell wrote:
Why is there pg_dumpall instead of a pg_dump with some flag?
pg_dumpall does all DBs plus the globals, but I'll have to let one of the
developers answer why
On Wed, Jan 17, 2007 at 01:18:06PM -0800, Jeff Frost wrote:
> On Wed, 17 Jan 2007, Ray Stell wrote:
> >Why is there pg_dumpall instead of a pg_dump with some flag?
>
> pg_dumpall does all DBs plus the globals, but I'll have to let one of the
> developers answer why there isn't just a flag for pg_
On Wed, 17 Jan 2007, Ray Stell wrote:
1. Curious about the difference in step 6 of this list, uses pg_restore, and
what is listed in the doc:
http://www.postgresql.org/docs/8.2/interactive/install-upgrading.html
which says to restore via:
psql -d postgres -f outputfile
It depends
Please reply-all when replying so everyone can help.
What I mean is that I have a physical server db1 which is old and meant to be
replaced by new shiny physical server db2.
Let me ask a different question, because it seems perhaps I didn't understand
your original email.
Are you just tryin
1. Curious about the difference in step 6 of this list, uses pg_restore, and
what is listed in the doc:
http://www.postgresql.org/docs/8.2/interactive/install-upgrading.html
which says to restore via:
psql -d postgres -f outputfile
Is this use of psql related to the fact that a pg
And of course, I should have made mention of the docs here:
http://www.postgresql.org/docs/8.1/interactive/migration.html
because it likely explains it better than I am. :-)
On Wed, 17 Jan 2007, Jeff Frost wrote:
You have to dump the original 7.4.9 version of the database and restore that
int
You have to dump the original 7.4.9 version of the database and restore that
into the 8.1.3 database server.
An example:
I have a server db1 which is running pg 7.4.9
I have a server db2 which is to replace db1 running pg 8.1.3
I would likely just do something like this from db2 (assuming no c
Please clear something up for me. The database I'm trying to upgrade was/is
empty; only the original installation was present, no tables. Exactly what is
it I'm supposed to be dumping? If you mean making a copy of the original
8.1.3, that I've done before, but I'm unclear as to the meaning of
Andrew,
If you're moving between major versions, a dump/restore is necessary. The
proper procedure is:
1) pg_dump the old database by using the new version of pg_dump (8.1.x)
against the old db server (7.4.9 in your case)
2) stop the old database server (and possibly move/rename the old dat
I was requested to load data (a full copy of the db in question) from one
postgres database into another (empty) db on another system. Both of these
systems are running SuSE 9.2 Linux, for the record. It turned out that the two
systems were running different versions of postgres; the first sys
Yes, I guess that is true with 8.2 but with a few configurations for WAL
copying scripts.
Saw the following in documentation that specifies a good flow for doing it
--> http://www.postgresql.org/docs/8.2/static/warm-standby.html
---
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On
Shoaib Mir wrote:
Even with ver 8.1 you can use WAL archive backups (PITR) to implement
an incremental backup strategy.
Yes, true, but it's harder with 8.1 as you always have to start from a
base backup and roll WAL logs forward - without a custom script you
cannot "wait" for new WAL logs to ar
Even with ver 8.1 you can use WAL archive backups (PITR) to implement an
incremental backup strategy.
-
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 1/17/07, Andy Shellam (Mailing Lists) <
[EMAIL PROTECTED]> wrote:
I believe the option for a "warm standby" (which sounds like i
I believe the option for a "warm standby" (which sounds like it is what
you need) was made available in 8.2.0.
You'd have to look at the manual though, I haven't had time to
investigate, and I'm not sure whether it's cluster-wide, or
database-specific.
Yogvinder Singh wrote:
Hi Ppl,
I have
Hi Ppl,
I have Two PostgreSQL Database Servers. The situation is like this:-
1) On first database server ball the operations (i.e live server) will be done.
This server may contain n number of databases.
2) On the second database server, i want to keep one particular database (from
the first d
20 matches
Mail list logo
