Skip site navigation (1) Skip section navigation (2)

Re: Updated version of pg_receivexlog

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updated version of pg_receivexlog
Date: 2011-10-27 12:00:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Oct 27, 2011 at 7:19 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 27.10.2011 14:09, Fujii Masao wrote:
>> On Thu, Oct 27, 2011 at 7:48 PM, Magnus Hagander<magnus(at)hagander(dot)net>
>>  wrote:
>>> I'm rewriting the handling of partial files per the other thread
>>> started by Heikki. The idea is that there will be an actual .partial
>>> file in there when pg_receivexlog has ended, and you have to deal with
>>> it manually. The typical way would be to pad it with zeroes to the
>>> end. Doing such padding would solve this recovery issue, correct?
>> Yes. But that sounds unuserfriendly. Padding the WAL file manually
>> is easy-to-do for a user?
> "truncate -s 16M <file>" works at least on my Linux system. Not sure how
> you'd do it on Windows.

One of the common I hear about PostgreSQL is that our replication
system is more difficult to set up than people would like, and it's
too easy to make mistakes that can corrupt your data without realizing
it; I don't think making them need to truncate a file to 16 megabytes
is going to improve things there.

> Perhaps we should add automatic padding in the server, though. It wouldn't
> take much code in the server, and would make life easier for people writing
> their scripts. Maybe even have the backend check for a .partial file if it
> can't find a regularly named XLOG file. Needs some thought..

+1 for figuring out something, though I'm not sure exactly what.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Florian PflugDate: 2011-10-27 12:03:23
Subject: Re: Hot Backup with rsync fails at pg_clog if under load
Previous:From: Robert HaasDate: 2011-10-27 11:36:37
Subject: Re: Hot Backup with rsync fails at pg_clog if under load

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group