On Tue, Mar 29, 2016 at 1:11 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Mar 29, 2016 at 2:28 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> I definitely prefer that, that's neater! libpq_select could be
>> simplified because a timeout does not matter much.
>
> Ok, here is a new version that exits the streaming loop correctly when
> endofwal becomes true. To hit that codepath you have to set up a
> cascading standby with recovery_target_timeline = 'latest', and then
> promote the standby it's talking to. I also got rid of the
> PostmasterIsAlive() check which became superfluous.
Yes, I can see the difference.
> You're right that libpq_select is now only ever called with timeout =
> -1 so could theoretically lose the parameter, but I decided against
> cluttering this patch up by touching that for now. It seems like the
> only reason it's used by libpqrcv_PQexec is something to do with
> interrupts on Windows, which I'm not able to test so that was another
> reason not to touch it.
OK. I don't mind if the first patch is bare-bone. That's additional cleanup.
> (BTW, isn't the select call in libpq_select
> lacking an exceptfds set, and can't it therefore block forever when
> there is an error condition on the socket and no timeout?)
Hm. I think you're right here when timeout is NULL... It would loop infinitely.
@Andres (in CC): your thoughts on that regarding the new
WaitEventSetWaitBlock()? The same pattern is used there.
-bool walrcv_receive(int timeout, unsigned char *type, char **buffer, int *len)
-
-Retrieve any message available through the connection, blocking for
Oh, the description of walrcv_receive is actually incorrect in
src/backend/replication/README from the beginning... I am sure you
noticed that as well. Perhaps that's worth fixing in the back-branches
(I think it does matter). Thoughts from others?
OK, so I am switching this patch as "Ready for committer", for 0001.
It is in better shape now.
--
Michael