Re: [HACKERS] Named restore points

2011-02-24 Thread Robert Haas
On Thu, Feb 24, 2011 at 10:28 AM, Euler Taveira de Oliveira wrote: > The following patch implements the Thom's suggestions. > > [1] http://archives.postgresql.org/message-id/4d48209c.7050...@timbira.com Committed with some additional wordsmithing. -- Robert Haas EnterpriseDB: http://www.enterpr

Re: [HACKERS] Named restore points

2011-02-24 Thread Euler Taveira de Oliveira
Em 08-02-2011 17:35, Thom Brown escreveu: This could do with a bit more documentation about usage. Below the Backup Control Functions table (http://developer.postgresql.org/pgdocs/postgres/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE), each function has a paragraph detailing what it does.

Re: [HACKERS] Named restore points

2011-02-08 Thread Fujii Masao
On Wed, Feb 9, 2011 at 4:53 AM, Simon Riggs wrote: > Committed. Thanks for the patch and the review. - * We also track the timestamp of the latest applied COMMIT/ABORT record - * in XLogCtl->recoveryLastXTime, for logging purposes. + * We also track the timestamp of the latest applied COMMIT/ABOR

Re: [HACKERS] Named restore points

2011-02-08 Thread Thom Brown
On 8 February 2011 19:53, Simon Riggs wrote: > On Tue, 2011-02-08 at 14:07 -0300, Euler Taveira de Oliveira wrote: > >> Because named restore point is a noop xlog record; besides, transaction and >> time involves xlog records that contain data. > > Committed. Thanks for the patch and the review. >

Re: [HACKERS] Named restore points

2011-02-08 Thread Simon Riggs
On Tue, 2011-02-08 at 14:07 -0300, Euler Taveira de Oliveira wrote: > Because named restore point is a noop xlog record; besides, transaction and > time involves xlog records that contain data. Committed. Thanks for the patch and the review. I changed the patch to require wal_level > minimal, r

Re: [HACKERS] Named restore points

2011-02-08 Thread Simon Riggs
On Tue, 2011-02-08 at 14:07 -0300, Euler Taveira de Oliveira wrote: > > Not sure I understand the comment "only make sense when we're dealing > > with transaction or time." Why? > > > Because named restore point is a noop xlog record; besides, transaction and > time involves xlog records that co

Re: [HACKERS] Named restore points

2011-02-08 Thread Euler Taveira de Oliveira
Em 08-02-2011 11:05, Simon Riggs escreveu: On Fri, 2011-02-04 at 21:15 -0500, Jaime Casanova wrote: + else if (recoveryTarget == RECOVERY_TARGET_NAME) + snprintf(buffer, sizeof(buffer), +"%s%u\t%s\t%s named restore point % s\n", +

Re: [HACKERS] Named restore points

2011-02-08 Thread Simon Riggs
On Fri, 2011-02-04 at 21:15 -0500, Jaime Casanova wrote: > > > > + else if (recoveryTarget == RECOVERY_TARGET_NAME) > > + snprintf(buffer, sizeof(buffer), > > +"%s%u\t%s\t%s named restore point % > s\n", > > +(srcfd

Re: [HACKERS] Named restore points

2011-02-08 Thread Simon Riggs
On Tue, 2011-02-08 at 08:05 -0500, Robert Haas wrote: > On Tue, Feb 8, 2011 at 2:05 AM, Jaime Casanova wrote: > >> 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

Re: [HACKERS] Named restore points

2011-02-08 Thread Robert Haas
On Tue, Feb 8, 2011 at 2:05 AM, Jaime Casanova wrote: >> 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 >> wi

Re: [HACKERS] Named restore points

2011-02-07 Thread Jaime Casanova
On Mon, Feb 7, 2011 at 10:59 PM, Robert Haas wrote: > On Fri, Feb 4, 2011 at 9:15 PM, Jaime Casanova 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 Read

Re: [HACKERS] Named restore points

2011-02-07 Thread Robert Haas
On Fri, Feb 4, 2011 at 9:15 PM, Jaime Casanova 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? -- Robert Haas

Re: [HACKERS] Named restore points

2011-02-04 Thread Jaime Casanova
On Tue, Feb 1, 2011 at 10:02 AM, Euler Taveira de Oliveira wrote: > Em 14-01-2011 17:41, Jaime Casanova escreveu: >> >> Here is a patch that implements "named restore points". >> > Sorry, I was swamped with work. :( > > Your patch no longer applied so I rebased it and slightly modified it. > Revie

Re: [HACKERS] Named restore points

2011-02-01 Thread Euler Taveira de Oliveira
Em 14-01-2011 17:41, Jaime Casanova escreveu: Here is a patch that implements "named restore points". Sorry, I was swamped with work. :( Your patch no longer applied so I rebased it and slightly modified it. Review is below... + The default is to recover to the end of the WAL log. +

Re: [HACKERS] Named restore points

2011-01-30 Thread Robert Haas
On Fri, Jan 14, 2011 at 8:33 PM, Euler Taveira de Oliveira wrote: > OK. I will review your patch at the beginning of the week. Euler, are you still planning to review this? We're running out of time. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] Named restore points

2011-01-14 Thread Jaime Casanova
On Fri, Jan 14, 2011 at 8:33 PM, Euler Taveira de Oliveira wrote: > > OK. I will review your patch at the beginning of the week. > thanks -- Jaime Casanova         www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] Named restore points

2011-01-14 Thread Euler Taveira de Oliveira
Em 14-01-2011 19:50, Jaime Casanova escreveu: On Fri, Jan 14, 2011 at 5:42 PM, Euler Taveira de Oliveira wrote: Em 14-01-2011 17:41, Jaime Casanova escreveu: Here is a patch that implements "named restore points". Nice feature. I only read the provided documentation and it seems inconsiste

Re: [HACKERS] Named restore points

2011-01-14 Thread Simon Riggs
On Fri, 2011-01-14 at 17:18 -0500, Tom Lane wrote: > Jaime Casanova writes: > > Here is a patch that implements "named restore points". > > > It allows DBAs to specify an exact point to which they can recover > > but that point will have a name, so they have a better control of when > > they wan

Re: [HACKERS] Named restore points

2011-01-14 Thread Robert Haas
On Fri, Jan 14, 2011 at 3:41 PM, Jaime Casanova wrote: > Here is a patch that implements "named restore points". > > It allows DBAs to specify  an exact point to which they can recover > but that point will have a name, so they have a better control of when > they want to stop recovery (ie: DBA's

Re: [HACKERS] Named restore points

2011-01-14 Thread Jaime Casanova
On Fri, Jan 14, 2011 at 5:42 PM, Euler Taveira de Oliveira wrote: > Em 14-01-2011 17:41, Jaime Casanova escreveu: >> >> Here is a patch that implements "named restore points". >> > Nice feature. I only read the provided documentation and it seems > inconsistent to allow name, time, and xid at reco

Re: [HACKERS] Named restore points

2011-01-14 Thread Euler Taveira de Oliveira
Em 14-01-2011 17:41, Jaime Casanova escreveu: Here is a patch that implements "named restore points". Nice feature. I only read the provided documentation and it seems inconsistent to allow name, time, and xid at recovery_target_name because (i) someone could name the recovery point as '123456

Re: [HACKERS] Named restore points

2011-01-14 Thread Tom Lane
Jaime Casanova writes: > Here is a patch that implements "named restore points". > It allows DBAs to specify an exact point to which they can recover > but that point will have a name, so they have a better control of when > they want to stop recovery (ie: DBA's won't depend of remember > specif

[HACKERS] Named restore points

2011-01-14 Thread Jaime Casanova
Hi, Here is a patch that implements "named restore points". It allows DBAs to specify an exact point to which they can recover but that point will have a name, so they have a better control of when they want to stop recovery (ie: DBA's won't depend of remember specific times, dates and such). T