Re: Sync Rep for 2011CF1
От | Heikki Linnakangas |
---|---|
Тема | Re: Sync Rep for 2011CF1 |
Дата | |
Msg-id | 4D5BEFF9.6020906@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Sync Rep for 2011CF1 (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Sync Rep for 2011CF1
|
Список | pgsql-hackers |
On 16.02.2011 17:36, Simon Riggs wrote: > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao<masao.fujii@gmail.com> wrote: >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas >>> <heikki.linnakangas@enterprisedb.com> wrote: >>>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also >>>> sends a status update every time the WAL is flushed. If the walreceiver is >>>> busy receiving and flushing, that would happen once per WAL segment, which >>>> seems sensible. >>> >>> This change can make the callback function "WalRcvDie()" call ereport(ERROR) >>> via XLogWalRcvFlush(). This looks unsafe. >> >> Good catch. Is the cleanest solution to pass a boolean parameter to >> XLogWalRcvFlush() indicating whether we're in the midst of dying? > > Surely if you do this then sync rep will fail to respond correctly if > WalReceiver dies. > > Why is it OK to write to disk, but not OK to reply? Because the connection might be dead. A broken connection is a likely cause of walreceiver death. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: