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).
>
>
>
>
>
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) |
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) |
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) |