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

Re: Updated version of pg_receivexlog

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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 09:25:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Oct 27, 2011 at 5:18 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> Not sure I follow. When we arrive at PQgetCopyData() there should be
> nothing buffered, and if the end of stream happens there it returns
> -1, and we exit, no? So where is the data that's lost?
> I do realize we don't actually fsync() and close() in this case - is
> that what you are referring to? But the data should already have been
> write()d, so it should still be there, no?

Oh, right. Hmm.. xlogdump might be the cause.

Though I've not read the code of xlogdump, I wonder if it gives up
outputting the contents of WAL file when it finds a partial WAL page...
This strikes me that recovery code has the same problem. No?
IOW, when a partial WAL page is found during recovery, I'm afraid
that page would not be replayed though it contains valid data.


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-10-27 09:37:48
Subject: Re: Hot Backup with rsync fails at pg_clog if under load
Previous:From: Magnus HaganderDate: 2011-10-27 08:18:48
Subject: Re: Updated version of pg_receivexlog

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