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

Поиск
Список
Период
Сортировка
От MauMau
Тема Re: Serious problem: media recovery fails after system or PostgreSQL crash
Дата
Msg-id BBE4CD52C6514703A9AB604AB6655757@maumau
обсуждение исходный текст
Ответ на Re: Serious problem: media recovery fails after system or PostgreSQL crash  ("Kevin Grittner" <kgrittn@mail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: why can't plpgsql return a row-expression?
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: optimized DROP of multiple tables within a transaction