Re: PITR COPY Failure (was Point in Time Recovery)

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PITR COPY Failure (was Point in Time Recovery)
Date: 2004-07-21 02:39:18
Message-ID: 40FDD756.9030005@coretech.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers pgsql-patches

This is presumably a standard feature of any PITR design - if the
failure event destroys the current transaction log, then you can only
recover transactions that committed in the last *archived* log.

regards

Mark

Simon Riggs wrote:

>
>The test works, but gives what looks like strange results: the test
>blows away the data directory completely, so the then-current xlog dies
>too. That contained the commit for the large COPY, so even though the
>recovery now works, the table has zero rows in it. (When things die
>you're still likely to lose *some* data).
>
>
>
>
>

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Mike G 2004-07-21 05:19:14 Re: Invalid User ID: 0
Previous Message Mark Kirkwood 2004-07-21 02:27:49 Re: PITR COPY Failure (was Point in Time Recovery)

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Sherry 2004-07-21 02:55:28 Re: Patch for pg_dump: Multiple -t options and new -T
Previous Message Mark Kirkwood 2004-07-21 02:27:49 Re: PITR COPY Failure (was Point in Time Recovery)

Browse pgsql-patches by date

  From Date Subject
Next Message Gavin Sherry 2004-07-21 02:55:28 Re: Patch for pg_dump: Multiple -t options and new -T
Previous Message Mark Kirkwood 2004-07-21 02:27:49 Re: PITR COPY Failure (was Point in Time Recovery)