From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: On-demand running query plans using auto_explain and signals |
Date: | 2015-09-02 09:16:21 |
Message-ID: | CAFj8pRDxTM6X0bC+hp75d+UqyRiPPC8cPbPbLx7vzYePa4H_CA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2015-09-02 11:01 GMT+02:00 Shulgin, Oleksandr <oleksandr(dot)shulgin(at)zalando(dot)de>
:
> On Tue, Sep 1, 2015 at 7:02 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>>
>>> But do we really need the slots mechanism? Would it not be OK to just
>>> let the LWLock do the sequencing of concurrent requests? Given that we
>>> only going to use one message queue per cluster, there's not much
>>> concurrency you can gain by introducing slots I believe.
>>>
>>
>> I afraid of problems on production. When you have a queue related to any
>> process, then all problems should be off after end of processes. One
>> message queue per cluster needs restart cluster when some pathological
>> problems are - and you cannot restart cluster in production week, sometimes
>> weeks. The slots are more robust.
>>
>
> Yes, but in your implementation the slots themselves don't have a
> queue/buffer. Did you intend to have a message queue per slot?
>
The message queue cannot be reused, so I expect one slot per caller to be
used passing parameters, - message queue will be created/released by demand
by caller.
>
> What sort of pathological problems are you concerned of? The
> communicating backends should just detach from the message queue properly
> and have some timeout configured to prevent deadlocks. Other than that, I
> don't see how having N slots really help the problem: in case of
> pathological problems you will just deplete them all sooner or later.
>
I afraid of unexpected problems :) - any part of signal handling or
multiprocess communication is fragile. Slots are simple and simply attached
to any process without necessity to alloc/free some memory.
Pavel
>
> --
> Alex
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2015-09-02 09:41:13 | Re: Horizontal scalability/sharding |
Previous Message | Shulgin, Oleksandr | 2015-09-02 09:01:00 | Re: On-demand running query plans using auto_explain and signals |