From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Thom Brown <thom(at)linux(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |
Date: | 2016-03-28 13:08:26 |
Message-ID: | CAEepm=3rRsKztJg-4BOu80TsHpYSO5YGmiSkzwOv_d=RjBCNMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 29, 2016 at 1:56 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Mon, Mar 28, 2016 at 8:54 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> I have been also thinking a lot about this patch, and the fact that
>> the WAL receiver latch is being used within the internals of
>> libpqwalreceiver has been bugging me a lot, because this makes the
>> wait phase happening within the libpqwalreceiver depend on something
>> that only the WAL receiver had a only control on up to now (among the
>> things thought: having a second latch for libpqwalreceiver, having an
>> event interface for libpqwalreceiver, switch libpq_receive into being
>> asynchronous...).
>
> Yeah, it bugs me too. Do you prefer this?
>
> int walrcv_receive(char **buffer, int *wait_fd);
>
> Return value -1 means end-of-copy as before, return value 0 means "no
> data available now, please call me again when *wait_fd is ready to
> read". Then walreceiver.c can look after the WaitLatchOrSocket call
> and deal with socket readiness, postmaster death, timeout and latch,
> and libpqwalreceiver.c doesn't know anything about all that stuff
> anymore, but it is now part of the interface that it must expose a
> file descriptor for readiness testing when it doesn't have data
> available.
>
> Please find attached a new patch series which does it that way.
Oops, there is a bug in the primary disconnection case when len == 1
and it breaks out of the loop and wait_fd is invalid. I'll follow up
on that tomorrow, but I'm interested to hear your thoughts (and anyone
else's!) on that interface change and general approach.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-03-28 13:09:04 | Re: Move PinBuffer and UnpinBuffer to atomics |
Previous Message | Thomas Munro | 2016-03-28 12:56:28 | Re: Proposal: "Causal reads" mode for load balancing reads without stale data |