Обсуждение: WAL Archiving under Windows
Hi Has anybody got any expierience with PITR recovery under Windows. PostgreSQL just doesn't seem to copy the WAL Files to the acrive location. We have done the initial backup and the first wal file was copied, but after that, it seems to ignore the newer ones. We now have two more wal filex in pg_xlog that were not transferred to the archive directory. We use version 8.1.3 and the following archive_coomand: archive_command = 'copy %p d:\\backup\\logs\%f' Bye Tim
Tim Tassonis wrote:
> Hi
>
> Has anybody got any expierience with PITR recovery under Windows.
> PostgreSQL just doesn't seem to copy the WAL Files to the acrive
> location. We have done the initial backup and the first wal file was
> copied, but after that, it seems to ignore the newer ones. We now have
> two more wal filex in pg_xlog that were not transferred to the archive
> directory.
>
> We use version 8.1.3 and the following archive_coomand:
>
> archive_command = 'copy %p d:\\backup\\logs\%f'
^^^
Could the lack of a double-backslash be causing the problem?
--
Richard Huxton
Archonet Ltd
Richard Huxton wrote: > Tim Tassonis wrote: >> Hi >> >> Has anybody got any expierience with PITR recovery under Windows. >> PostgreSQL just doesn't seem to copy the WAL Files to the acrive >> location. We have done the initial backup and the first wal file was >> copied, but after that, it seems to ignore the newer ones. We now have >> two more wal filex in pg_xlog that were not transferred to the archive >> directory. >> >> We use version 8.1.3 and the following archive_coomand: >> >> archive_command = 'copy %p d:\\backup\\logs\%f' > ^^^ > Could the lack of a double-backslash be causing the problem? > Sorry, that was a problem on my quoting. The config file reads: archive_command = 'copy %p d:\\backup\\logs\\%f' Bye Tim
Tim Tassonis wrote: >>> We use version 8.1.3 and the following archive_coomand: >>> >>> archive_command = 'copy %p d:\\backup\\logs\%f' >> ^^^ >> Could the lack of a double-backslash be causing the problem? >> > > Sorry, that was a problem on my quoting. The config file reads: > > > archive_command = 'copy %p d:\\backup\\logs\\%f' Hmm - in that case I'd be tempted to wrap it in a small script so you can log the parameters passed in and return code passed out. -- Richard Huxton Archonet Ltd
Hi!
> archive_command = 'copy %p d:\\backup\\logs\\%f'
I think you should try something like this:
archive_command = 'copy %p d:/backup/logs/%f'
(using single / instead of \\).
In documentation it is said:
restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
So I think the same format of command line sould be used for copying WAL files.
Taras Kopets
Richard Huxton wrote: > Tim Tassonis wrote: >>>> We use version 8.1.3 and the following archive_coomand: >>>> >>>> archive_command = 'copy %p d:\\backup\\logs\%f' >>> ^^^ >>> Could the lack of a double-backslash be causing the problem? >>> >> >> Sorry, that was a problem on my quoting. The config file reads: >> >> >> archive_command = 'copy %p d:\\backup\\logs\\%f' > > Hmm - in that case I'd be tempted to wrap it in a small script so you > can log the parameters passed in and return code passed out. > The strange thing is, even with loglevel debug5, I don't get any log message indicating that postgres is even trying to call the command. Is there only anything in the logfile if the copying succeeds or are there cases where postgres thinks it doesn't have to copy them. From what I understand, the wal files should be copied fairly often, so if postgres breaks, everything is at the (hopefully still intact) archive location. Bye Tim
Tim Tassonis <timtas@cubic.ch> writes:
> The strange thing is, even with loglevel debug5, I don't get any log
> message indicating that postgres is even trying to call the command.
Then it isn't, because there are definitely log messages, which were
specifically put there for the purpose of recording the fully-expanded
archive command string:
ereport(DEBUG3,
(errmsg_internal("executing archive command \"%s\"",
xlogarchcmd)));
rc = system(xlogarchcmd);
if (rc != 0)
{
ereport(LOG,
(errmsg("archive command \"%s\" failed: return code %d",
xlogarchcmd, rc)));
return false;
}
ereport(LOG,
(errmsg("archived transaction log file \"%s\"", xlog)));
Better double-check the usual sorts of gotchas, like whether you are
editing the right config file and properly forcing a config reload
afterwards.
regards, tom lane
Hi Tom Tom Lane wrote: > Tim Tassonis <timtas@cubic.ch> writes: >> The strange thing is, even with loglevel debug5, I don't get any log >> message indicating that postgres is even trying to call the command. > > Then it isn't, because there are definitely log messages, which were > specifically put there for the purpose of recording the fully-expanded > archive command string: I must be, as I increased the debug level and that actually took place. I did get more log messages. Is there anything else that could prevent the archiving from taking place, without giving any message?
Tim Tassonis wrote: > Hi Tom > > Tom Lane wrote: >> Tim Tassonis <timtas@cubic.ch> writes: >>> The strange thing is, even with loglevel debug5, I don't get any log >>> message indicating that postgres is even trying to call the command. >> >> Then it isn't, because there are definitely log messages, which were >> specifically put there for the purpose of recording the fully-expanded >> archive command string: > > I must be, as I increased the debug level and that actually took place. > I did get more log messages. > > Is there anything else that could prevent the archiving from taking > place, without giving any message? Did you check Tom's suggestion that you haven't got a duplicate postgresql.conf somewhere? -- Richard Huxton Archonet Ltd
Hi Tom Richard Huxton wrote: > Tim Tassonis wrote: >> Hi Tom >> >> Tom Lane wrote: >>> Tim Tassonis <timtas@cubic.ch> writes: >>>> The strange thing is, even with loglevel debug5, I don't get any log >>>> message indicating that postgres is even trying to call the command. >>> >>> Then it isn't, because there are definitely log messages, which were >>> specifically put there for the purpose of recording the fully-expanded >>> archive command string: >> >> I must be, as I increased the debug level and that actually took >> place. I did get more log messages. >> >> Is there anything else that could prevent the archiving from taking >> place, without giving any message? > > Did you check Tom's suggestion that you haven't got a duplicate > postgresql.conf somewhere? > As I said, other changes in the config file did have an effect, so that hardly can be the issue. Bye Tim
Tim Tassonis wrote: > Hi Tom > > Richard Huxton wrote: >> Tim Tassonis wrote: >>> Hi Tom >>> >>> Tom Lane wrote: >>>> Tim Tassonis <timtas@cubic.ch> writes: >>>>> The strange thing is, even with loglevel debug5, I don't get any >>>>> log message indicating that postgres is even trying to call the >>>>> command. >>>> >>>> Then it isn't, because there are definitely log messages, which were >>>> specifically put there for the purpose of recording the fully-expanded >>>> archive command string: >>> >>> I must be, as I increased the debug level and that actually took >>> place. I did get more log messages. >>> >>> Is there anything else that could prevent the archiving from taking >>> place, without giving any message? >> >> Did you check Tom's suggestion that you haven't got a duplicate >> postgresql.conf somewhere? >> > As I said, other changes in the config file did have an effect, so that > hardly can be the issue. Could it be that for some reason the WAL backup config isn't being picked up? Stray non-printing character? Typo? Try "show all". If that fails I'd think the quickest thing might be to initdb an alternative installation, run it on a different port with its own config file and push a load of rows through it. See if that picks up your WAL backup script. If it does, then it must be something with your config file. If not, then it's something in the code. -- Richard Huxton Archonet Ltd