Jay McGaffigan writes:
> So my first question.
> If I can't use a psql 9.2.2 instance to create the backup. Are there
> 'best' practices I should follow in creating the backup. All my googling
> hasn't really been able to point to the best approach.
We do recommend using the newer pg_dump in
If Tom's suggestion doesn't work, can you do your text dump by schema,
or for a subset of tables, and see if you can isolate the problem
table. (using the -n or -t options)
Have you changed the locale / languages settings between db versions?
If you find a quoting problem in a very large table you
Jay McGaffigan writes:
> I've been trying to restore a fairly sizeable database dump from my
> production server onto my dev box.
> Recently upgraded to 9.2.2 and wanted to try it out.
> So I grabbed a text dump of the database and tried the "Createdb dbname;
> psql < dmpfile" way of restoring
On 02/08/2013 12:43 PM, Jay McGaffigan wrote:
Hi,
I've been trying to restore a fairly sizeable database dump from my
production server onto my dev box.
Recently upgraded to 9.2.2 and wanted to try it out.
So I grabbed a text dump of the database and tried the "Createdb
dbname; psql < dmpfi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane ha scritto:
> Pavel Stehule writes:
>> 2010/3/13 Manlio Perillo :
>>> Usually when I need to restore a database to its initial state, what I
>>> do is to simply drop it, and then re-create it.
>>> However on a shared hosting this is not possi
Pavel Stehule writes:
> 2010/3/13 Manlio Perillo :
>> Usually when I need to restore a database to its initial state, what I
>> do is to simply drop it, and then re-create it.
>> However on a shared hosting this is not possible.
> Usually people use a install and a uninstall scripts. First create
Hyho!
On Saturday 13 March 2010 13.48:14 Manlio Perillo wrote:
> Usually when I need to restore a database to its initial state, what I
> do is to simply drop it, and then re-create it.
>
> However on a shared hosting this is not possible.
Create a schema, modify your default search path so tha
Hello
2010/3/13 Manlio Perillo :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi.
>
> Usually when I need to restore a database to its initial state, what I
> do is to simply drop it, and then re-create it.
>
> However on a shared hosting this is not possible.
>
> By initial state I mean:
Chris Henderson wrote:
pg_dumpall archive. If you look at the backup file, you'll find that
it's just straight SQL. If you want to restore a particular database
out of it and not all of them, then you will need to edit the sql file
to include only what you want to restore. Then you simply pass
> pg_dumpall archive. If you look at the backup file, you'll find that
> it's just straight SQL. If you want to restore a particular database
> out of it and not all of them, then you will need to edit the sql file
> to include only what you want to restore. Then you simply pass it
> through psq
Jeff Frost wrote:
> Chris Henderson wrote:
>
>> I backup all my databases by using pg_dumpall - pg_dumpall >
>> /tmp/postgres.backup.`hostname`. It should backup four DBs: analyze,
>> postgres, template0 and template1
>> I guess this backs up the schemas as well.
>>
>> Now I want to restore o
Chris Henderson wrote:
> I backup all my databases by using pg_dumpall - pg_dumpall >
> /tmp/postgres.backup.`hostname`. It should backup four DBs: analyze,
> postgres, template0 and template1
> I guess this backs up the schemas as well.
>
> Now I want to restore one of the databases and schema fr
On 15/10/2008 22:19, Chris Henderson wrote:
> I backup all my databases by using pg_dumpall - pg_dumpall >
> /tmp/postgres.backup.`hostname`. It should backup four DBs: analyze,
> postgres, template0 and template1
> I guess this backs up the schemas as well.
>
> Now I want to restore one of the d
On Wed, Oct 15, 2008 at 3:19 PM, Chris Henderson <[EMAIL PROTECTED]> wrote:
> I backup all my databases by using pg_dumpall - pg_dumpall >
> /tmp/postgres.backup.`hostname`. It should backup four DBs: analyze,
> postgres, template0 and template1
> I guess this backs up the schemas as well.
>
> Now
Thanks to everyone for for the myriad of informative replies on this.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
William Garrison wrote:
We have a SAN volume, and we created a tablespace that that points to
that SAN volume (Z: drive). This put all the table files on Z:. It
was our assumption that the table files + the archived transaction
would now be on the Z: drive, and that was enough to restore the
William Garrison wrote:
> I have just come to a horrible realization about PostgreSQL that I'm
> sure is supposed to be pre-requisite knowledge even going into this. So
> everyone may laugh at me now.
>
> We have a SAN volume, and we created a tablespace that that points to
> that SAN volume (Z:
On Wed, Aug 27, 2008 at 6:16 PM, William Garrison <[EMAIL PROTECTED]> wrote:
>
> I'm still reeling from the thought that there can
> somehow be a single transaction log for multiple databases. How is that
> even possible? Are the transaction ID numbers shared across databases too?
Yes it's poss
Alvaro Herrera wrote:
> It is consistent only if it was taken when the postmaster was down.
OR if you are able to take a point-in-time snapshot at the volume level,
say using LVM or some SAN management tool. The effect is the same as if
the server is hardware reset unexpectedly, in that it requir
William Garrison wrote:
[snip]
> A database is not just tables - it is tables and
> transaction logs. Why on earth would PostgreSQL put the tables
> separately from the transaction logs?
Because you told it to. If you want everything on Z:\postgresql you just
initdb that location and point PG at
I have just come to a horrible realization about PostgreSQL that I'm
sure is supposed to be pre-requisite knowledge even going into this. So
everyone may laugh at me now.
We have a SAN volume, and we created a tablespace that that points to
that SAN volume (Z: drive). This put all the table
William Garrison wrote:
> 1) I have a file system backup that *IS* consistent. So I should not
> need any WAL files at all right?
It is consistent only if it was taken when the postmaster was down.
> **update**
> I got it working. Here's how
> 1) I have a file system snapshot. No WAL files
Alvaro Herrera wrote:
William Garrison wrote:
I have a PostgreSQL database on Windows Server 2003, and the database is
kept on a SAN that has the ability to make instantaneous snapshots.
Once I have made such a snapshot, I am unclear how to re-attach it to
another postgres database on a
Sorry Alvaro, i sent to you the message ;P
Is the same way (from snapshot) that use Mysql on ZFS.
IF you don't change anything in the database, why it don't works?
Then you restart the service with the same path.
The problem it will be that you need to stop postgres BEFORE snapshot.
--
Sent
William Garrison wrote:
> I have a PostgreSQL database on Windows Server 2003, and the database is
> kept on a SAN that has the ability to make instantaneous snapshots.
> Once I have made such a snapshot, I am unclear how to re-attach it to
> another postgres database on another machine. Po
> Any suggestions? Is my procedure correct? Would I need to also copy
> the transaction logs or something like that?
the 'by the book' procedure for this operation is to use
pg_dumpall . > dump_file.sql
and later
psql -f dump_file.sql postgres
pg_dumpall gives you a transaction
o de 2006 14:00
Para: [EMAIL PROTECTED]; Postgres general mailing list
Assunto: RE: [GENERAL] RESTORING A DATABASE WITH DIFFERENT TIMEZONES
'2006-12-20 00:00:00-02' and '2006-12-19 23:00:00-03' *are* the same
time. You *did* preserve it. Is your application unaware of timezone?
If
On Dec 21, 2006, at 11:32 , Rodrigo Sakai wrote:
But I have to restore it and maintain the same value of datetime!
How can I do it?
You should have no problem. A timestamp with time zone marks an
absolute instant in time: the different time zones are different
representations of the s
'2006-12-20 00:00:00-02' and '2006-12-19 23:00:00-03' *are* the same
time. You *did* preserve it. Is your application unaware of timezone?
If you want the server to behave like it's in a different time zone that
where it actually is, configure the locale in postgresql.conf.
http://www.postgresq
29 matches
Mail list logo
