From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support for N synchronous standby servers |
Date: | 2014-08-13 07:10:38 |
Message-ID: | CAB7nPqQOq4JjZshT+YbrroUsLkdvBuo7MH1UyCEGFewSmgSGTg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 13, 2014 at 2:10 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> I sent the SIGSTOP signal to the walreceiver process in one of sync standbys,
> and then ran write transactions again. In this case, they must not be completed
> because their WAL cannot be replicated to the standby that its walreceiver
> was stopped. But they were successfully completed.
At the end of SyncRepReleaseWaiters, SYNC_REP_WAIT_WRITE and
SYNC_REP_WAIT_FLUSH in walsndctl were able to update with only one wal
sender in sync, making backends wake up even if other standbys did not
catch up. But we need to scan all the synchronous wal senders and find
the minimum write and flush positions and update walsndctl with those
values. Well that's a code path I forgot to cover.
Attached is an updated patch fixing the problem you reported.
Regards,
--
Michael
Attachment | Content-Type | Size |
---|---|---|
20140813_multi_syncrep_v3.patch | text/x-patch | 22.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2014-08-13 07:49:50 | Re: WAL format and API changes (9.5) |
Previous Message | Pavel Stehule | 2014-08-13 05:22:24 | Re: proposal for 9.5: monitoring lock time for slow queries |