| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Mike Mascari <mascarm(at)mascari(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Recovery Features |
| Date: | 2004-07-05 23:22:26 |
| Message-ID: | 1089069746.17493.142.camel@stromboli |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2004-07-05 at 23:40, Mike Mascari wrote:
> Simon Riggs wrote:
>
> >
> > ...Nobody is shouting YES, so its a dodo...
>
> The point at which the above process becomes
> too complex (or less than obvious) for hand-recovery is precisely
> when unforeseen consequences of nixing a single transaction become
> too great.
>
Agreed. The potential for unforeseen consequences is just too high, and
although I'm fairly sure they would always be spotted during recovery
and cause an error - I think it is something that requires proof. And I
don't have that. So, lets leave that idea alone for 100 years.
> ... hand-recovery ...
hmmm...not sure I know what you mean.
It is very-very-close-to-impossible to edit the transaction logs
manually, unless some form of special-format editor were written for the
purpose.
Is it clear that the PITR features are completely different from
pg_dump? (Which would allow a manual edit and recover). The xlogs are
binary files that refer to all changes to all tables in a cluster
ordered by time, rather than by table.
Best regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike Mascari | 2004-07-05 23:30:21 | Re: Recovery Features |
| Previous Message | Gaetano Mendola | 2004-07-05 23:20:20 | Re: [BUGS] [CHECKER] 4 memory leaks in Postgresql 7.4.2 |