Re: Proposal for 9.1: WAL streaming from WAL buffers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal for 9.1: WAL streaming from WAL buffers
Date: 2010-06-16 02:01:07
Message-ID: AANLkTimILTTzaTYNqg1-UC3JaQqIN0MxQiPykNgEx_G_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 15, 2010 at 8:09 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> I have yet to convince myself of how likely this is to occur.  I tried
>> to reproduce this issue by crashing the database, but I think in 9.0
>> you need an actual operating system crash to cause this problem, and I
>> haven't yet set up an environment in which I can repeatedly crash the
>> OS.  I believe, though, that in 9.1, we're going to want to stream
>> from WAL buffers as proposed in the patch that started out this
>> thread, and then I think this issue can be triggered with just a
>> database crash.
>
> Yes, but it still requires:
>
> a) the master must crash with at least one transaction transmitted to
> the slave an not yet fsync'd

Bzzzzt. Stop right there. It only requires the master to crash with
at least one *WAL record* written but not transmitted, not one
transaction. And most WAL record types are not fsync'd immediately.
So in theory I think that, for example, an OS crash in the middle of a
big bulk insert operation should be sufficient to trigger this.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-06-16 02:55:24 Re: hstore ==> and deprecate =>
Previous Message Robert Haas 2010-06-16 01:58:23 Re: hstore ==> and deprecate =>