WAL Archiving under Windows

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