Re: Serious problem: media recovery fails after system or PostgreSQL crash

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Kevin Grittner" <kgrittn(at)mail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Serious problem: media recovery fails after system or PostgreSQL crash
Date: 2012-12-06 22:33:29
Message-ID: BBE4CD52C6514703A9AB604AB6655757@maumau
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: "Kevin Grittner" <kgrittn(at)mail(dot)com>
> If you are attempting a PITR-style recovery and you want to include
> WAL entries from the partially-copied file, pad a copy of it with
> NUL bytes to the expected length.

I'm afraid This is unacceptably difficult, or almost impossible, for many PG
users. How do you do the following?

1. Identify the file type (WAL segment, backup history file, timeline
history file) and its expected size in the archive_command script.
archive_command has to handle these three types of files. Embedding file
name logic (e.g. WAL is 000000010000000200000003) in archive_command is a
bad idea, because the file name might change in the future PG release.

2. Append NUL bytes to the file in the archive_command shell script or batch
file. Particularly I have no idea about Windows. I have some PG systems
running on Windows. This would compromise the ease of use of PostgreSQL.

So I believe PG should handle the problem, not the archive_command.

Regards
MauMau

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2012-12-06 22:38:59 Re: PATCH: optimized DROP of multiple tables within a transaction
Previous Message Tom Lane 2012-12-06 22:01:16 Re: why can't plpgsql return a row-expression?