From: | JD Wong <jdmswong(at)gmail(dot)com> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | Lonni J Friedman <netllama(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: broke postgres, how to fix?? |
Date: | 2013-03-01 16:50:26 |
Message-ID: | CAGuHHn8OUAYjMpOC6XkSOgVf8gicTbijgdmSrm+ZNJ8puyNmqQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thank you everybody for your help,
This problem has been resolved, in part to your insights.
All the best,
-JD
On Fri, Mar 1, 2013 at 4:31 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>wrote:
> JD Wong wrote:
> >>> Hi Adrian, yes I completely copied the config-file and data directories
> >>> over.
>
> >> That's guaranteed to break everything badly.
>
> > Even if I "read only style" copied the files? Do you mind elaborating on
> why this happens? ( or point
> > me to relevant documentation )
>
> The problem is that if you copy the files of a running database,
> these files will change while they are being copied.
> This can result in unusable contents.
> Also, to function properly, the different files
> in a PostgreSQL data directory must be consistent with each other.
> If you copy one file after the other, files that are copied later
> might belong to a different state of the database than earlier files.
>
> You either have to shutdown the database before copying
> (a filesystem level offline backup) or use some instantaneous
> snapshotting technique that your file system might offer.
> In the latter case PostgreSQL should perform crash recovery
> and eventually reach a consistent state.
>
> Yours,
> Laurenz Albe
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jordan Glassman | 2013-03-01 19:13:24 | “custom archiver out of memory” error when restoring large DB using pg_restore |
Previous Message | Merlin Moncure | 2013-03-01 14:37:19 | Re: Poor performance when using a window function in a view |