Re: [EXTERNAL] Re: Support load balancing in libpq

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: [EXTERNAL] Re: Support load balancing in libpq
Дата
Msg-id CAAWbhmhj4HoYp=_Y-6Q_iSP+BWzT1zTX27UTE60uUTKwsJfZaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [EXTERNAL] Re: Support load balancing in libpq  (Jelte Fennema <postgres@jeltef.nl>)
Ответы Re: [EXTERNAL] Re: Support load balancing in libpq  (Jacob Champion <jchampion@timescale.com>)
Список pgsql-hackers
On Fri, Jan 13, 2023 at 9:10 AM Jelte Fennema <postgres@jeltef.nl> wrote:
>
> > Just a quick single-issue review, but I agree with Maxim that having
> > one PRNG, seeded once, would be simpler
>
> I don't agree that it's simpler. Because now there's a mutex you have
> to manage, and honestly cross-platform threading in C is not simple.
> However, I attached two additional patches that implement this
> approach on top of the previous patchset. Just to make sure that
> this patch is not blocked on this.

It hadn't been my intention to block the patch on it, sorry. Just
registering a preference.

I also didn't intend to make you refactor the locking code -- my
assumption was that you could use the existing pglock_thread() to
handle it, since it didn't seem like the additional contention would
hurt too much. Maybe that's not actually performant enough, in which
case my suggestion loses an advantage.

> > The test seed could then be handled globally as well (envvar?) so that you
> > don't have to introduce a debug-only option into the connection string.
>
> Why is a debug-only envvar any better than a debug-only connection option?
> For now I kept the connection option approach, since to me they seem pretty
> much equivalent.

I guess I worry less about envvar namespace pollution than pollution
of the connection options. And my thought was that the one-time
initialization could be moved to a place that doesn't need to know the
connection options at all, to make it easier to reason about the
architecture. Say, next to the WSAStartup machinery.

But as it is now, I agree that the implementation hasn't really lost
any complexity compared to the original, and I don't feel particularly
strongly about it. If it doesn't help to make the change, then it
doesn't help.

Thanks,
--Jacob



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Следующее
От: Nikolay Samokhvalov
Дата:
Сообщение: Re: Transaction timeout