Martijn van Oosterhout writes:
> On Mon, 16 Sep 2019 at 15:33, Tom Lane wrote:
>> But do we care? With asyncQueueAdvanceTail gone from the listeners,
>> there's no longer an exclusive lock for them to contend on. And,
>> again, I failed to see any significant contention even in HEAD as it
>>
Hoi Tom,
On Mon, 16 Sep 2019 at 15:33, Tom Lane wrote:
>
> Martijn van Oosterhout writes:
> > I think I like the idea of having SignalBackend do the waking up a
> > slow backend but I'm not enthused by the "lets wake up (at once)
> > everyone that is behind". That's one of the issues I was
Martijn van Oosterhout writes:
> On Mon, 16 Sep 2019 at 00:14, Tom Lane wrote:
>> ... I also think we
>> can simplify the handling of other-database listeners by including
>> them in the set signaled by SignalBackends, but only if they're
>> several pages behind. So that leads me to the
Hoi Tom,
On Mon, 16 Sep 2019 at 00:14, Tom Lane wrote:
>
> I spent some more time thinking about this, and I'm still not too
> satisfied with this patch's approach. It seems to me the key insights
> we're trying to make use of are:
>
> 1. We don't really need to keep the global tail pointer
Martijn van Oosterhout writes:
> On Sat, 14 Sep 2019 at 17:08, Tom Lane wrote:
>> None of this seems to respond to my point: it looks to me like it would
>> work fine if you simply dropped the patch's additions in PreCommit_Notify
>> and ProcessCompletedNotifies, because there is already enough
On Sat, 14 Sep 2019 at 17:08, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > On Fri, 13 Sep 2019 at 22:04, Tom Lane wrote:
> >> But, really ... do we need the backendTryAdvanceTail flag at all?
> None of this seems to respond to my point: it looks to me like it would
> work fine if you
Martijn van Oosterhout writes:
> On Fri, 13 Sep 2019 at 22:04, Tom Lane wrote:
>> But, really ... do we need the backendTryAdvanceTail flag at all?
> There are multiple issues here. asyncQueueReadAllNotifications() is
> going to be called by each listener simultaneously, so each listener
> is
Hoi Tom,
On Fri, 13 Sep 2019 at 22:04, Tom Lane wrote:
>
> This throws multiple compiler warnings for me:
Fixed.
> Also, I don't exactly believe this bit:
[snip]
> It seems unlikely that insertion would stop exactly at a page boundary,
> but that seems to be what this is looking for.
This is
Martijn van Oosterhout writes:
> Here is the rebased second patch.
This throws multiple compiler warnings for me:
async.c: In function 'asyncQueueUnregister':
async.c:1293: warning: unused variable 'advanceTail'
async.c: In function 'asyncQueueAdvanceTail':
async.c:2153: warning:
Hoi Tom,
On Wed, 11 Sep 2019 at 00:18, Tom Lane wrote:
>
> I pushed 0001 after doing some hacking on it --- it was sloppy about
> datatypes, and about whether the invalid-entry value is 0 or -1,
> and it was just wrong about keeping the list in backendid order.
> (You can't conditionally skip
Martijn van Oosterhout writes:
> The original three patches have been collapsed into one as given the
> changes discussed it didn't make sense to keep them separate. There
> are now two patches (the third is just to help with testing):
> Patch 1: Tracks the listening backends in a list so
Hoi hackers,
Here is a reworked version of the previous patches.
The original three patches have been collapsed into one as given the
changes discussed it didn't make sense to keep them separate. There
are now two patches (the third is just to help with testing):
Patch 1: Tracks the listening
12 matches
Mail list logo
