| From: | Magnus Hagander <magnus(at)hagander(dot)net> |
|---|---|
| To: | Christian Ullrich <chris(at)chrullrich(dot)net> |
| Cc: | tuanhoanganh <hatuan05(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: PostgreSQL 9.0.1 PITR can not copy WAL file |
| Date: | 2011-01-19 20:52:58 |
| Message-ID: | AANLkTimy0RCPDqVWSk8b6BAR7N0zUCmdr4TKnZm+qoH6@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, Jan 19, 2011 at 19:20, Christian Ullrich <chris(at)chrullrich(dot)net> wrote:
> * tuanhoanganh wrote:
>
>> I have checked your solution.
>
>> - Target disk full : No
>> - PostgreSQL user does not have write privilege for the target directory
>> : No
>> - Target file exists already (then you have a bigger problem) : Last
>> file in D:/3SDATABACKUP/PITR/WAL is 00000001000000040000005D
>
>> - PostgreSQL user does not have full control privileges for the source
>> file (the copy command needs them) : i switch to user postgres an copy
>> 00000001000000040000005E from source to d:\temp and create new text file
>> on D:/3SDATABACKUP/PITR/WAL it is ok. No access denied
>
> So when PostgreSQL runs "copy 000...5E D:\...", it fails, and when you do
> the same thing as the PostgreSQL user, it works. Interesting. Try increasing
> the log level in postgresql.conf to see if it logs the error message from
> copy, or try xcopy instead of copy.
Note thatn when PostgreSQL runs, it will shed any rights given through
"Administrators" or "Power Users" group. So this is not an identical
test.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John R Pierce | 2011-01-19 20:56:02 | Re: PostgreSQL 9.0.1 PITR can not copy WAL file |
| Previous Message | Tom Lane | 2011-01-19 20:38:18 | Re: Error during a dump (ts_selectivity, not found) |