Re: Named restore points

On Mon, Feb 7, 2011 at 10:59 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Feb 4, 2011 at 9:15 PM, Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
>> ok, i will see you're reviewed version later today
>
> This patch is still marked as "Needs Review" in the CommitFest
> application, but I'm thinking perhaps it should be changed to Ready
> for Committer?  Are there any open issues?
>

only things i can found are:

> + static char recoveryStopNamedRestorePoint[MAXFNAMELEN];
>
> Is MAXFNAMELEN appropriate? AFAICS it is used for file name length. [Looking
> at code...] It seems to be used for backup label too so it is not so
> inappropriate.
>

which is just a question about if MAXFNAMELEN is the right length to use

and

> Finally, this is a nice feature iif we have a way to know what named restore
> points are available. DBAs need to take note of this list (that is not good)
> and the lazy ones will have a hard time to recover the right name (possibly
> with a xlog dump tool).
>
> So how could we store this information? Perhaps a file in
> $PGDATA/pg_xlog/restore_label that contains the label (and possibly the WAL
> location). Also it must have a way to transmit the restore_label when we add
> another restore point. I didn't implement this part (Jaime?) and it seems as
> important as the new xlog record type that is in the patch. It seems
> complicate but I don't have ideas. Anyone? The restore point names could be
> obtained by querying a function (say, pg_restore_point_names or
> pg_restore_point_list).
>

i still think this should be a separate tool or a dba written list,
the reason beign that with sql function we were not able track restore
points in archived segments... if you like i can try to build a simple
tool for this but don't think that is a showstopper, even without that
the feature is useful IMHO at least

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL