Re: Serious problem: media recovery fails after system or PostgreSQL crash - Mailing list pgsql-hackers

From MauMau
Subject Re: Serious problem: media recovery fails after system or PostgreSQL crash
Date
Msg-id BBE4CD52C6514703A9AB604AB6655757@maumau
Whole thread Raw
In response to Re: Serious problem: media recovery fails after system or PostgreSQL crash  ("Kevin Grittner" <kgrittn@mail.com>)
List pgsql-hackers
From: "Kevin Grittner" <kgrittn@mail.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







pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: why can't plpgsql return a row-expression?
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: optimized DROP of multiple tables within a transaction