* tuanhoanganh wrote:
I have changed archive_command to
archive_command = 'copy %p D:\\3SDATABACKUP\\PITR\\WAL\\%f'
and it work again.
Argh. How could I not have seen that?
But why old archive_command work from 01/01 to 05/01
archive_command = 'copy %p D:/3SDATABACKUP/PITR/WAL/%f'
It works
I have changed archive_command to
archive_command = 'copy %p D:\\3SDATABACKUP\\PITR\\WAL\\%f'
and it work again.
But why old archive_command work from 01/01 to 05/01
archive_command = 'copy %p D:/3SDATABACKUP/PITR/WAL/%f'
Thank for your help
Tuan Hoang ANh
On Fri, Jan 21, 2011 at 8:58 PM, Christi
* tuanhoanganh wrote:
Here is procmon i thinks error
[some procmon events]
No, that is all OK. The event at 2:39:55.7588651 is where Postgres
starts cmd.exe to perform the copy. The really interesting data would be
from cmd.exe itself, which implements the copy command.
Please send the eve
* tuanhoanganh wrote:
I download postgresql from Enterprise DB
On Thu, Jan 20, 2011 at 6:06 AM, Christian Ullrich mailto:ch...@chrullrich.net>> wrote:
We cannot assume that the one-click installer was used, but if it
was, the service account it creates will be a member of the Users
I download postgresql from Enterprise DB
On Thu, Jan 20, 2011 at 6:06 AM, Christian Ullrich wrote:
> * Magnus Hagander wrote:
>
> On Wed, Jan 19, 2011 at 19:20, Christian Ullrich
>> wrote:
>>
>
> So when PostgreSQL runs "copy 000...5E D:\...", it fails, and when you do
>>> the same thing as th
NO, D is local driver.
I setup PITR from 01/01/2011. It work well from 01->05/01/2011
(D:/3SDATABACKUP/PITR/WAL has 00010004005D) but error from
06/01/2011
On Thu, Jan 20, 2011 at 3:56 AM, John R Pierce wrote:
> On 01/19/11 9:23 AM, tuanhoanganh wrote:
>
>>
>>
>>2011-01-06 08
* Magnus Hagander wrote:
On Wed, Jan 19, 2011 at 19:20, Christian Ullrich wrote:
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
On 01/19/11 9:23 AM, tuanhoanganh wrote:
2011-01-06 08:27:54 ICT LOG: archive command failed with exit
code 1
2011-01-06 08:27:54 ICT DETAIL: The failed archive command
was: copy
pg_xlog\00010004005E
D:/3SDATABACKUP/PITR/WAL/0001
On Wed, Jan 19, 2011 at 19:20, Christian Ullrich 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) : Las
* 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 00010004005D
- Post
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 00010004005D
- PostgreSQL user does not have full
* tuanhoanganh wrote:
My PITR work well from 01/01/2011 to 06/01/2011. At 06/01/2011
postgresql log have issue
2011-01-06 08:27:54 ICT LOG: archive command failed with exit code 1
2011-01-06 08:27:54 ICT DETAIL: The failed archive command was: copy
pg_xlog\00010004005E
D:/3SDATA
My PITR work well from 01/01/2011 to 06/01/2011. At 06/01/2011 postgresql
log have issue
2011-01-06 08:27:48 ICT LOG: autovacuum: found orphan temp table
"pg_temp_19"."cdvt13newtmp" in database "cpnvn_data"
2011-01-06 08:27:48 ICT LOG: autovacuum: found orphan temp table
"pg_temp_49"."tmpct70s" i
13 matches
Mail list logo
