| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "J(dot) R(dot) Nield" <jrnield(at)usol(dot)com> |
| Cc: | PostgreSQL Patch List <pgsql-patches(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Subject: | Re: Point in time recovery 20020822_01_pitr.patch |
| Date: | 2002-08-23 05:43:08 |
| Message-ID: | 17453.1030081388@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"J. R. Nield" <jrnield(at)usol(dot)com> writes:
> On Fri, 2002-08-23 at 00:29, Tom Lane wrote:
>> Why don't you log the operations symbolically, viz "create database foo
>> with template bar"? I can't see any reason to insist on a finer level
>> of detail than that.
> If you do symbolic logging like that, it forecloses any chance of adding
> individual relation recovery, because the template might be ahead of the
> log.
We are already assuming that the template database is stable while it's
being copied. While there are obvious risks in that assumption, I don't
think that you need to eliminate the assumption as an essential
component of PITR ... and I think that there are a number of issues
that'd have to be solved that are completely unrelated to PITR (eg, how
do you lock a table that's in a database you aren't in, and indeed that
you don't even know exists, because you can't read the pg_class table
that describes it?) My advice: this is a job not to tackle for version
1, and maybe not for version 2, 3, or 4...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2002-08-23 06:46:50 | Re: Proposed GUC Variable |
| Previous Message | J. R. Nield | 2002-08-23 05:27:09 | Re: Point in time recovery 20020822_01_pitr.patch |