|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstandby.sgml,v 2.5 2008/05/07 18:48:40 alvherre Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstandby.sgml,v 2.6 2008/12/15 22:08:35 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <sect1 id="pgstandby"> |
4 | 4 | <title>pg_standby</title> |
@@ -295,7 +295,16 @@ restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p |
295 | 295 | </itemizedlist> |
296 | 296 |
|
297 | 297 | <para> |
298 | | - Since the Windows example uses <literal>copy</> at both ends, either |
| 298 | + The <literal>copy</> command on Windows sets the final file size |
| 299 | + before the file is completely copied, which would ordinarly confuse |
| 300 | + <application>pg_standby</application>. Therefore |
| 301 | + <application>pg_standby</application> waits <literal>sleeptime</> |
| 302 | + seconds once it sees the proper file size. GNUWin32's <literal>cp</> |
| 303 | + sets the file size only after the file copy is complete. |
| 304 | + </para> |
| 305 | + |
| 306 | + <para> |
| 307 | + Using the Since the Windows example uses <literal>copy</> at both ends, either |
299 | 308 | or both servers might be accessing the archive directory across the |
300 | 309 | network. |
301 | 310 | </para> |
|