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

From Magnus Hagander
Subject Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.
Date
Msg-id CABUevEzQCpN_g1-m3MZCTZpEK++NR9+xvqXtWZvmkBaxDeirJw@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Wed, Nov 19, 2014 at 6:16 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Nov 17, 2014 at 12:30 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Mon, Nov 17, 2014 at 10:02 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> On Sat, Nov 15, 2014 at 9:10 PM, Michael Paquier
>>> <michael.paquier@gmail.com> wrote:
>>>> 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?
>> Makes sense. What about a check using reportFlushPosition then?
>
> Sounds reasonable. Thanks for updating the patch!
> But the patch could not already be applied to the master cleanly
> because c4f99d2 heavily changed the code that the patch also touches...
> I rewrote the patch and pushed it to both master and REL9_4_STABLE.
> Anyway, thanks!

Is this:

+       if (reportFlushPosition && lastFlushPosition < blockpos &&
+           walfile != 1)

really correct? Shouldn't that walfile test be against -1 (minus one)?


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: postgres_fdw behaves oddly
Next
From:
Date:
Subject: Re: Customized Options Threshold Error