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.
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 |