I wrote:
> I've been poking into the src/test/subscription TAP tests, thinking
> that they seem a lot slower than they ought to be. The first thing
> I came across was this bit in WaitForReplicationWorkerAttach():
> /*
> * We need timeout because we generally don't get notified v
On 30/06/17 04:46, Tom Lane wrote:
> Petr Jelinek writes:
>> On 30/06/17 02:07, Tom Lane wrote:
>>> I'm also kind of wondering why the "behind the apply" path out of
>>> LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much
>>> better off if we just let the sync worker exit alw
Petr Jelinek writes:
> On 30/06/17 02:07, Tom Lane wrote:
>> I'm also kind of wondering why the "behind the apply" path out of
>> LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much
>> better off if we just let the sync worker exit always as soon as it's done
>> the initial s
On 30/06/17 02:07, Tom Lane wrote:
> I'm also kind of wondering why the "behind the apply" path out of
> LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much
> better off if we just let the sync worker exit always as soon as it's done
> the initial sync, letting any extra catch
Hi,
On 2017-06-29 20:07:14 -0400, Tom Lane wrote:
> I was able to make the hang go away by means of the attached patch that
> allows WalSndWaitForWal to exit early if the client has shut down the
> COPY. However, since that function is miserably underdocumented (like
> most of this code :-(), I h
I've been poking into the src/test/subscription TAP tests, thinking
that they seem a lot slower than they ought to be. The first thing
I came across was this bit in WaitForReplicationWorkerAttach():
/*
* We need timeout because we generally don't get notified via latch
*
