Review of last summer's PITR patch
От | Tom Lane |
---|---|
Тема | Review of last summer's PITR patch |
Дата | |
Msg-id | 25856.1076553698@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Review of last summer's PITR patch
Re: Review of last summer's PITR patch |
Список | pgsql-hackers-pitr |
I've done some preliminary work on the PITR patch that J.R. Nield developed last summer. I've applied parts of it (in rather edited form) but there are big chunks I think are not ready to go. You can see the original patch in pgsql-patches --- I sent it there mostly to get it into the archives. I have committed the parts that have to do with making the contents of WAL more robust for PITR purposes; specifically, labeling WAL segment files clearly, and adding WAL logging of file creation/deletion. I have not committed the massive reorganization of xlog.c that appears in J.R.'s patch; I think it's unnecessary and likely to introduce bugs (certainly it would revert some recent bug fixes). I have also not committed the ALTER SYSTEM BACKUP / ALTER SYSTEM RECOVER commands that appear in the patch. It is not clear to me that this functionality belongs in the backend rather than separate management utilities, and even if it does belong there, this doesn't seem a clean way to do it. On the backup side, it seems like this code is basically reinventing the tar(1) command. On the restore side, I don't care for the "interactive command" implementation of ALTER SYSTEM RECOVER --- that seems like it makes it unnecessarily hard to drive the recovery process from another program. I envision this process being controlled by some kind of higher-level management utility, so I'd prefer to see a program-friendly API instead of one designed for manual use. Anyway, I'm hoping to see some discussion of what to do next and what the PITR functionality ought to look like from a user's standpoint. regards, tom lane
В списке pgsql-hackers-pitr по дате отправления: