|
1 | 1 | <!-- |
2 | | -$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.41 2004/08/03 23:42:59 tgl Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.42 2004/08/04 17:37:09 tgl Exp $ |
3 | 3 | --> |
4 | 4 | <chapter id="backup"> |
5 | 5 | <title>Backup and Restore</title> |
@@ -891,6 +891,35 @@ restore_command = 'cp /mnt/server/archivedir/%f %p' |
891 | 891 | timelines that branched off earlier than the base backup. |
892 | 892 | </para> |
893 | 893 | </sect2> |
| 894 | + |
| 895 | + <sect2 id="backup-online-caveats"> |
| 896 | + <title>Caveats</title> |
| 897 | + |
| 898 | + <para> |
| 899 | + At this writing, there are several limitations of the on-line backup |
| 900 | + technique. These will probably be fixed in future releases. |
| 901 | + |
| 902 | + <itemizedlist> |
| 903 | + <listitem> |
| 904 | + <para> |
| 905 | + The effects of <command>CREATE DATABASE</>, <command>DROP DATABASE</>, |
| 906 | + <command>CREATE TABLESPACE</>, and <command>DROP TABLESPACE</> are |
| 907 | + not fully reflected in the WAL log. It is recommended that you take |
| 908 | + a new base backup after performing one of these operations. |
| 909 | + </para> |
| 910 | + </listitem> |
| 911 | + <listitem> |
| 912 | + <para> |
| 913 | + Operations on non-btree indexes (hash, R-tree, and GiST indexes) are |
| 914 | + not presently WAL-logged, so replay will not update these index types. |
| 915 | + The recommended workaround, if you use any non-btree indexes, is to |
| 916 | + manually <command>REINDEX</> each such index after completing a |
| 917 | + recovery operation. |
| 918 | + </para> |
| 919 | + </listitem> |
| 920 | + </itemizedlist> |
| 921 | + </para> |
| 922 | + </sect2> |
894 | 923 | </sect1> |
895 | 924 |
|
896 | 925 | <sect1 id="migration"> |
|