Re: loss of transactions in streaming replication

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: loss of transactions in streaming replication
Date: 2011-10-19 16:05:52
Message-ID: CA+TgmobT7HTjTstaB7tHXBHaA+nBNTYHAqQOp=dYpKKUyYwTig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 19, 2011 at 10:41 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Oct 19, 2011 at 9:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> The original behavior, in 9.0, is that all outstanding WAL are
>>> replicated to the standby when the master shuts down normally.
>>> But ISTM the behavior was changed unexpectedly in 9.1. So
>>> I think that it should be back-patched to 9.1 to revert the behavior
>>> to the original.
>>
>> Which commit broke this?
>
> d3d414696f39e2b57072fab3dd4fa11e465be4ed
> b186523fd97ce02ffbb7e21d5385a047deeef4f6
>
> The former introduced problematic libpqrcv_send() (which was my mistake...),
> and the latter is the first user of it.

OK, so this is an artifact of the changes to make libpq communication
bidirectional. But I'm still confused about where the error is coming
from. In your OP, you wrote "In 9.2dev and 9.1, when walreceiver
detects an error while sending data to WAL stream, it always emits
ERROR even if there are data available in the receive buffer." So
that implied to me that this is only going to trigger if you have a
shutdown together with an awkwardly-timed error. But your scenario
for reproducing this problem doesn't seem to involve an error.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-10-19 16:10:18 Re: new compiler warnings
Previous Message Greg Jaskiewicz 2011-10-19 16:05:43 Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)