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
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 => |