Re: POC: Extension for adding distributed tracing - pg_tracing

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: POC: Extension for adding distributed tracing - pg_tracing
Дата
Msg-id CAGRY4nyo-qenpdOfDcriUD4E350d7-+on1=xf=M8NL4QsBt23w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: POC: Extension for adding distributed tracing - pg_tracing  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
Ответы Re: POC: Extension for adding distributed tracing - pg_tracing  (Aleksander Alekseev <aleksander@timescale.com>)
Список pgsql-hackers
Дерево обсуждения


On Tue, 12 Mar 2024, 23:45 Anthonin Bonnefoy, <anthonin.bonnefoy@datadoghq.com> wrote:

> - I don't think it's a good idea to do memory allocations in the middle of a
> PG_CATCH. If the error was due to out-of-memory, you'll throw another error.
Good point. I was wondering what were the risks of generating spans
for errors. I will try to find a better way to handle this.

The usual approach is to have pre-allocated memory. This must actually be written (zeroed usually) or it might be lazily allocated only on page fault. And it can't be copy on write memory allocated once in postmaster startup then inherited by fork.

That imposes an overhead for every single postgres backend. So maybe there's a better solution.

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Introduce XID age and inactive timeout based replication slot invalidation
Следующее
От: "Zhijie Hou (Fujitsu)"
Дата:
Сообщение: RE: Race condition in FetchTableStates() breaks synchronization of subscription tables