Re: On-demand running query plans using auto_explain and signals

Поиск
Список
Период
Сортировка
От Shulgin, Oleksandr
Тема Re: On-demand running query plans using auto_explain and signals
Дата
Msg-id CACACo5SjZwDp7K6zmFkz_-9u8CZvJ5i+jZN8-zDCgV7ZgJ=Okg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: On-demand running query plans using auto_explain and signals  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: On-demand running query plans using auto_explain and signals  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Tue, Sep 1, 2015 at 7:02 PM, Pavel Stehule <pavel.stehule@gmail.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?

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.

--
Alex

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Albe Laurenz
Дата:
Сообщение: Re: Horizontal scalability/sharding
Следующее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: Re: Proposal: Implement failover on libpq connect level.