On Wed, Oct 15, 2008 at 8:58 AM, Ivan Voras <[EMAIL PROTECTED]> wrote:
> 2008/10/15 Aidan Van Dyk <[EMAIL PROTECTED]>:
>> * Ivan Voras <[EMAIL PROTECTED]> [081015 10:05]:
>>
>>> So, pg_start_backup() freezes the data at the time it's called but still
>>> data and xlog are changed, in a different wa
Ivan Voras <[EMAIL PROTECTED]> writes:
> Matthew Wakeling wrote:
>> The files may change, but it doesn't matter, because there is enough
>> information in the xlog to correct it all.
> I'm thinking about these paragraphs in the documentation:
>> You can, however, omit from the backup dump the fil
2008/10/15 Aidan Van Dyk <[EMAIL PROTECTED]>:
> * Ivan Voras <[EMAIL PROTECTED]> [081015 10:05]:
>
>> So, pg_start_backup() freezes the data at the time it's called but still
>> data and xlog are changed, in a different way that's safe to backup? Why
>> not run with pg_start_backup() always enabled
2008/10/15 Ivan Voras <[EMAIL PROTECTED]>:
> Matthew Wakeling wrote:
>> On Wed, 15 Oct 2008, Ivan Voras wrote:
Nope. Even files in data directory change. That's why the documentation
warns against tools that emit errors for files that change during the
copy.
>>>
>>> Ok, thanks. This
Matthew Wakeling wrote:
> On Wed, 15 Oct 2008, Ivan Voras wrote:
>>> Nope. Even files in data directory change. That's why the documentation
>>> warns against tools that emit errors for files that change during the
>>> copy.
>>
>> Ok, thanks. This is a bit off-topic, but if it's not how I imagine i
On Wed, 15 Oct 2008, Ivan Voras wrote:
Nope. Even files in data directory change. That's why the documentation
warns against tools that emit errors for files that change during the copy.
Ok, thanks. This is a bit off-topic, but if it's not how I imagine it,
then how is it implemented?
The fil
Guillaume Lelarge wrote:
> Ivan Voras a écrit :
>> It looks like PostgreSQL freezes the state of the "data" directory in
>> this case (and new data goes only to the transaction log - pg_xlog),
>> which effectively creates an application-level snapshot. Good to know.
>
> Nope. Even files in data d
Ivan Voras a écrit :
> Jesper Krogh wrote:
>>[...]
>> It worked when I tested it, but I may just have been darn lucky.
>
> No, it should be ok - I just didn't catch up with the times :) At least
> that's my interpretation of this paragraph in documentation:
>
> """Some backup tools that you might
Jesper Krogh wrote:
> Ivan Voras wrote:
>> Warning: DO NOT do on-the-fly binary backups without snapshots.
>> Archiving the database directory with tar on a regular file system,
>> while the server is running, will result in an archive that most likely
>> won't work when restored.
>
> Even if you
Ivan Voras wrote:
Warning: DO NOT do on-the-fly binary backups without snapshots.
Archiving the database directory with tar on a regular file system,
while the server is running, will result in an archive that most likely
won't work when restored.
Even if you do a "pg_start_backup/pg_stop_backu
Ivan Voras wrote:
> Warning: DO NOT do on-the-fly binary backups without snapshots.
> Archiving the database directory with tar on a regular file system,
> while the server is running, will result in an archive that most likely
> won't work when restored.
You can do non-snapshot-based filesystem
Reuven M. Lerner wrote:
> But before I do any of these things, I want to hear what others have
> discovered in terms of high-performance backups. Is there a way to stop
> pg_dump from locking up the database so much? Is there a knob that I
> can turn to do a low-priority backup while the live si
Steve Crawford wrote:
You cannot keep the data in memory (that is, you can't disable writing
to the disk). But since you don't care about data loss, you could turn
off fsync in postgresql.conf. From a test perspective you should be fine
- it will only be an issue in the event of a crash and th
13 matches
Mail list logo
