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
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. Postgres seems to create
a directory
13 matches
Mail list logo
