| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Dave Page <dpage(at)pgadmin(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: odd output in restore mode |
| Date: | 2008-05-13 12:26:35 |
| Message-ID: | 482988FB.5070307@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
I wrote:
>
> However, we should probably make the behaviour switchable. If the
> archive_command populating the archive_directory were rsync, for
> example, this problem should not occur, because it copies to a temp
> file, and then renames it, so we should never see an incomplete file
> even though rsync also apparently preallocates space.
>
>
Another and probably simpler thing to try would be the GnuWin32 version
of cp. If we can verify that it behaves itself, we should probably
recommend it for use in archive_command instead of the native Windows copy.
I'm still not sure how to construct a test, though.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-05-13 13:44:14 | Re: Fairly serious bug induced by latest guc enum changes |
| Previous Message | Andrew Dunstan | 2008-05-13 12:00:29 | Re: odd output in restore mode |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-05-13 14:26:26 | Re: Making sure \timing is on |
| Previous Message | Andrew Dunstan | 2008-05-13 12:00:29 | Re: odd output in restore mode |