Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: furuyao(at)pm(dot)nttdata(dot)co(dot)jp
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, teranishih(at)nttdata(dot)co(dot)jp
Subject: Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.
Date: 2014-11-14 18:25:16
Message-ID: CAHGQGwFktEqmff5TrOYxDT9CiSd38g7HS9vua_TFONQDdBW7fA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 14, 2014 at 7:22 PM, <furuyao(at)pm(dot)nttdata(dot)co(dot)jp> wrote:
> Hi,
>
> "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.

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?

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-11-14 18:31:21 Re: pg_basebackup vs. Windows and tablespaces
Previous Message Andres Freund 2014-11-14 18:18:43 Re: Add CREATE support to event triggers