Re: [HACKERS]odd output in restore mode
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS]odd output in restore mode |
Дата | |
Msg-id | 488F28CB.8000201@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [HACKERS]odd output in restore mode (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: [HACKERS]odd output in restore mode
|
Список | pgsql-patches |
Andrew Dunstan wrote: > > > Greg Smith wrote: >> On Wed, 23 Jul 2008, Kevin Grittner wrote: >> >>> In our scripts we handle this by copying to a temp directory on the >>> same mount point as the archive directory and doing a mv to the >>> archive location when the copy is successfully completed. I think >>> that this even works on Windows. Could that just be documented as a >>> strong recommendation for the archive script? >> >> This is exactly what I always do. I think the way cp is shown in the >> examples promotes what's really a bad practice for lots of reasons, >> this particular problem being just one of them. >> >> I've been working on an improved archive_command shell script that I >> expect to submit for comments and potential inclusion in the >> documentation as a better base for other people to build on. This is >> one of the options for how it can operate. It would be painful but not >> impossible to convert a subset of that script to run under Windows as >> well, at least enough to cover this particular issue. > > A Perl script using the (standard) File::Copy module along with the > builtin function rename() should be moderately portable. It would to be > nice not to have to maintain two scripts. It's also not very nice to require a Perl installation on Windows, just for a replacement of Copy. Would a simple .bat script work? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: