Re: Sync Rep for 2011CF1
От | Simon Riggs |
---|---|
Тема | Re: Sync Rep for 2011CF1 |
Дата | |
Msg-id | 1297873941.1747.30561.camel@ebony обсуждение исходный текст |
Ответ на | Re: Sync Rep for 2011CF1 (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Sync Rep for 2011CF1
|
Список | pgsql-hackers |
On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote: > 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. Would it not be possible to check that? -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: