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

From Fujii Masao
Subject Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.
Date
Msg-id CAHGQGwGSnetTCFSCX-PGVUDOJRMTLwPVGb_XC+xSrjwKiNCX1w@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Wed, Nov 19, 2014 at 5:15 PM, Magnus Hagander <magnus@hagander.net> wrote:
> 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)?

Ooops... You're right. That's really mistake... Just fixed and pushed. Thanks!

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: postgres_fdw behaves oddly
Next
From: David Rowley
Date:
Subject: Re: Patch to support SEMI and ANTI join removal