I wrote:
> On further contemplation, it seems like the protocol needs another field
> besides that: each record should also carry a boolean indicating whether
> walsender.c thinks it is currently "caught up", ie the record carries
> all WAL data up to the current end of WAL.
Actually, there's a be
Fujii Masao writes:
> On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> That's intentional. It could take some time for the WAL to be sent, if
>>> the network is busy, so by the time XLogSend returns you might well not
>>> be caught up anymore.
>>
>> It may have
On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 02/06/10 21:44, Tom Lane wrote:
>>> In the current coding, the effect of not setting *caughtup here is just
>>> that we uselessly call XLogSend an extra time for each transmission
>>> (because the main loop won't e
On Wed, Jun 2, 2010 at 2:44 PM, Tom Lane wrote:
> I wrote:
>> I'm still inclined to apply the part of Simon's patch that adds a
>> transmit timestamp to each SR send chunk. That would actually be
>> completely unused by the slave given my proposal above, but I think that
>> it is an important ste
Tom Lane writes:
> Uh, if the slave is overloaded, *any* implementation will be playing
> catchup all the time. Not sure about your point here.
Well, sorry, I missed the part where the catchup is measured on
walsender side of things. Now that means that a non interrupted flow of
queries quicker
Dimitri Fontaine writes:
> I'm still trying to understand the implications of the proposal, which
> sounds good but⦠given just enough load on the slave, wouldn't it be
> playing catchup all the time?
Uh, if the slave is overloaded, *any* implementation will be playing
catchup all the time. No
Tom Lane writes:
> I wrote:
>> I'm still inclined to apply the part of Simon's patch that adds a
>> transmit timestamp to each SR send chunk. That would actually be
>> completely unused by the slave given my proposal above, but I think that
>> it is an important step to take to future-proof the
Heikki Linnakangas writes:
> On 02/06/10 21:44, Tom Lane wrote:
>> In the current coding, the effect of not setting *caughtup here is just
>> that we uselessly call XLogSend an extra time for each transmission
>> (because the main loop won't ever delay immediately after a
>> transmission). But wi
On 02/06/10 21:44, Tom Lane wrote:
In conjunction with that, I think there's a logic bug in XLogSend;
it ought to be changed like so:
/* if we went beyond SendRqstPtr, back off */
if (XLByteLT(SendRqstPtr, endptr))
+ {
endptr = SendRqstPtr;
+ *
I wrote:
> I'm still inclined to apply the part of Simon's patch that adds a
> transmit timestamp to each SR send chunk. That would actually be
> completely unused by the slave given my proposal above, but I think that
> it is an important step to take to future-proof the SR protocol against
> pos
10 matches
Mail list logo
