From: | Jaime Casanova <jaime(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Named restore points |
Date: | 2011-02-08 07:05:56 |
Message-ID: | AANLkTinp2i1mL1=do1G=PK2pzJ6u2un-w=LkHWQKgXYY@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-02-08 07:07:46 | Re: [COMMITTERS] pgsql: Implement genuine serializable isolation level. |
Previous Message | Pavel Stehule | 2011-02-08 07:00:42 | Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |