On Fri, Nov 30, 2018 at 04:44:37PM +0100, Dmitry Dolgov wrote:
> Thanks for the review. Just for the records, patch still has no conflicts and
> pass all the tests. Yura, do you have any plans about this patch, could you
> respond to the feedback? In the meantime I'm moving it to the next CF.
No a
> On Tue, Nov 6, 2018 at 5:19 AM Masahiko Sawada wrote:
>
> The idea of this patch seems reasonable.
>
> I've looked at this patch. This patch still can be applied cleanly to
> the current HEAD and passed regression tests.
>
> Here is review comments.
Thanks for the review. Just for the records,
On Wed, Oct 4, 2017 at 12:07 AM Sokolov Yura wrote:
>
> On 2017-10-03 17:30, Sokolov Yura wrote:
> > Good day, hackers.
> >
> > During hard workload sometimes process reaches deadlock timeout
> > even if no real deadlock occurred. It is easily reproducible with
> > pg_xact_advisory_lock on same va
On Mon, Jul 23, 2018 at 5:14 AM, Ashutosh Bapat
wrote:
> I think the case I am talking about is somewhere between these two -
> the backend which has imprecisely decided that there's a deadlock will
> start taking exclusive locks and will have to wait for all the
> backends with shared locks to re
On 3 October 2017 at 15:30, Sokolov Yura wrote:
> If hundreds of backends reaches this timeout trying to acquire
> advisory lock on a same value, it leads to hard-stuck for many
> seconds, cause they all traverse same huge lock graph under
> exclusive lock.
> During this stuck there is no possibi
On Sat, Jul 21, 2018 at 2:58 AM, Yura Sokolov wrote:
>
> It is regular pgbench output, so there is no source for confusion.
> tps numbers is number of transactions completed in that particular
> 5 second interval. That is why there are 0 tps and 1 tps intervals
> without patch. Which way 0tps and
11.07.2018 17:01, Ashutosh Bapat пишет:
> The patch still applies and it's part of this commitfest.
>
> On Tue, Oct 3, 2017 at 8:36 PM, Sokolov Yura wrote:
>> On 2017-10-03 17:30, Sokolov Yura wrote:
>>>
>>> Good day, hackers.
>>>
>>> During hard workload sometimes process reaches deadlock timeou
The patch still applies and it's part of this commitfest.
On Tue, Oct 3, 2017 at 8:36 PM, Sokolov Yura wrote:
> On 2017-10-03 17:30, Sokolov Yura wrote:
>>
>> Good day, hackers.
>>
>> During hard workload sometimes process reaches deadlock timeout
>> even if no real deadlock occurred. It is easil
