Re: POC: Extension for adding distributed tracing - pg_tracing

From: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Nikita Malakhov <hukutoc(at)gmail(dot)com>, Jan Katins <jasc(at)gmx(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Peter Smith <smithpb2250(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>
Subject: Re: POC: Extension for adding distributed tracing - pg_tracing
Date: 2024-03-13 04:28:55
Message-ID: CAGRY4nyo-qenpdOfDcriUD4E350d7-+on1=xf=M8NL4QsBt23w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 12 Mar 2024, 23:45 Anthonin Bonnefoy, <
anthonin(dot)bonnefoy(at)datadoghq(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2024-03-13 04:42:42 RE: Race condition in FetchTableStates() breaks synchronization of subscription tables
Previous Message Amit Kapila 2024-03-13 04:24:15 Re: Introduce XID age and inactive timeout based replication slot invalidation