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
each function has a paragraph detailing what it does.

I forgot to check it.

Also, I notice you can easily write over a label.  The case I'm
thinking of is someone in psql creating a named restore point, then
later on, they go in again, accidentally cursor up and select the
previous statement and create it again.  Would this mean that the
previous label is lost, or would it be the case that any subsequent
duplicate labels would have no effect unless the WAL files with the
original label in were consumed?  In either case, a note in the docs
about this would be useful.

This is a limitation that I pointed out [1] but people decided to postpone named restore point management. The first one is used as restore point. I added it in the attached patch.

And I don't see these label creations getting logged either.  Could we
output that to the log because at least then users can grep the
directory for labels, and, in most cases, the time they occurred?

Good point. I included location instead of time; time is already supplied by log file.

The following patch implements the Thom's suggestions.

[1] http://archives.postgresql.org/message-id/4d48209c.7050...@timbira.com

  Euler Taveira de Oliveira
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 736eb67..fe7e42b 100644
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*************** postgres=# select pg_start_backup('label
*** 14070,14075 ****
--- 14070,14084 ----
+    <function>pg_create_restore_point</> creates a named transaction log record
+    that can be used as recovery point, and then returns the transaction log
+    record location. The given name can be used in <xref
+    linkend="recovery-target-name"> that specifies the point up to which recovery
+    will proceed. Avoid creating restore points that have the same name, recovery
+    stops at the first one.
+    </para>
+    <para>
      <function>pg_current_xlog_location</> displays the current transaction log write
      location in the same format used by the above functions.  Similarly,
      <function>pg_current_xlog_insert_location</> displays the current transaction log
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 3ba1f29..b4eb4ac 100644
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
*************** XLogRestorePoint(const char *rpName)
*** 8144,8149 ****
--- 8144,8153 ----
  	RecPtr = XLogInsert(RM_XLOG_ID, XLOG_RESTORE_POINT, &rdata);
+ 	ereport(LOG,
+ 			(errmsg("restore point \"%s\" created at %X/%X",
+ 					rpName,	RecPtr.xlogid, RecPtr.xrecoff)));
  	return RecPtr;
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to