Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.
От | Fujii Masao |
---|---|
Тема | Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog. |
Дата | |
Msg-id | CAHGQGwH_aj1apxYi_zMpNw-aQrjsRdXFboZr-jB1VqEj_OFfbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog. (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: PostgreSQL doesn't stop propley when --slot option is
specified with pg_receivexlog.
|
Список | pgsql-hackers |
On Sat, Nov 15, 2014 at 9:10 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Sat, Nov 15, 2014 at 3:42 AM, Andres Freund <andres@2ndquadrant.com> wrote: >> On 2014-11-15 03:25:16 +0900, Fujii Masao wrote: >>> On Fri, Nov 14, 2014 at 7:22 PM, <furuyao@pm.nttdata.co.jp> wrote: >>> > "pg_ctl stop" does't work propley, if --slot option is specified when WAL is flushed only it has switched. >>> > These processes still continue even after the posmaster failed:pg_receivexlog, walsender and logger. >>> >>> I could reproduce this problem. At normal shutdown, walsender keeps waiting >>> for the last WAL record to be replicated and flushed in pg_receivexlog. But >>> pg_receivexlog issues sync command only when WAL file is switched. Thus, >>> since pg_receivexlog may never flush the last WAL record, walsender may have >>> to keep waiting infinitely. >> >> Right. > It is surprising that nobody complained about that before, > pg_receivexlog has been released two years ago. It's not so surprising because the problem can happen only when replication slot is specified, i.e., the version is 9.4 or later. >>> pg_recvlogical handles this problem by calling fsync() when it receives the >>> request of immediate reply from the server. That is, at shutdown, walsender >>> sends the request, pg_receivexlog receives it, flushes the last WAL record, >>> and sends the flush location back to the server. Since walsender can see that >>> the last WAL record is successfully flushed in pg_receivexlog, it can >>> exit cleanly. >>> >>> One idea to the problem is to introduce the same logic as pg_recvlogical has, >>> to pg_receivexlog. Thought? >> >> Sounds sane to me. Are you looking into doing that? > Yep, sounds a good thing to do if master requested answer from the > client in the keepalive message. Something like the patch attached > would make the deal. Isn't it better to do this only when replication slot is used? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: