Hi Anthonin,
> [...]
>
> 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
On Tue, 12 Mar 2024, 23:45 Anthonin Bonnefoy, <
anthonin.bonne...@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
Hi all!
Thanks for the reviews and comments.
> - pg_tracing.c should include postgres.h as the first thing
Will do.
> afaict none of the use of volatile is required, spinlocks have been barriers
> for a long time now
Got it, I will remove them. I've been mimicking what was done in
Hi,
On 2024-02-09 19:46:58 +0300, Nikita Malakhov wrote:
> I agree with Heikki on most topics and especially the one he recommended
> to publish your extension on GitHub, this tool is very promising for highly
> loaded
> systems, you will get a lot of feedback very soon.
>
> I'm curious about
Hi!
I agree with Heikki on most topics and especially the one he recommended
to publish your extension on GitHub, this tool is very promising for highly
loaded
systems, you will get a lot of feedback very soon.
I'm curious about SpinLock - it is recommended for very short operations,
taking up
Hi!
On Fri, Jan 26, 2024 at 1:43 PM Nikita Malakhov wrote:
> It's a good idea to split a big patch into several smaller ones.
> But you've already implemented these features - you could provide them
> as sequential small patches (i.e. v13-0002-guc-context-propagation.patch and
> so on)
Keeping
Hi!
On Fri, 2 Feb 2024 at 13:41, Heikki Linnakangas wrote:
> PS. Does any other DBMS implement this? Any lessons to be learned from
> them?
>
Mysql 8.3 has open telemetrie component, so very fresh:
https://dev.mysql.com/doc/refman/8.3/en/telemetry-trace-install.html
Hi Anthonin,
I'm only now catching up on this thread. Very exciting feature!
My first observation is that you were able to implement this purely as
an extension, without any core changes. That's very cool, because:
- You don't need buy-in or blessing from anyone else. You can just put
this
Hi!
It's a good idea to split a big patch into several smaller ones.
But you've already implemented these features - you could provide them
as sequential small patches (i.e. v13-0002-guc-context-propagation.patch
and so on)
Great job! I'm both hands for committing your patch set.
On Fri, Jan
2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures last time it was run [2]. Please have a
look and post an updated version if necessary.
==
[1] https://commitfest.postgresql.org/46/4456/
[2]
On Wed, 10 Jan 2024 at 15:55, Anthonin Bonnefoy
wrote:
> PREPARE test_prepared (text, integer) AS /*$1*/ SELECT $2;
> EXECUTE
> test_prepared('dddbs=''postgres.db'',traceparent=''00-0009-0009-01''',
> 1);
Wow, I had no idea that parameters could be
On Thu, Jan 4, 2024, 16:36 Anthonin Bonnefoy
wrote:
> > I used GUCs to set the `opentelemtery_trace_id` and `opentelemetry_span_id`.
> > These can be sent as protocol-level messages by the client driver if the
> > client driver has native trace integration enabled, in which case the user
> >
On Thu, 7 Dec 2023 at 20:06, Anthonin Bonnefoy
wrote:
>
> Hi,
>
> Thanks for the review!
>
> > ```
> > +-- Worker can take some additional time to end and report their spans
> > +SELECT pg_sleep(0.2);
> > + pg_sleep
> > +--
> > +
> > +(1 row)
> > ```
> >
> > Pretty sure this will fail on
Hi!
I've meant exactly the thing you mentioned -
>
> > By queries you mean particular queries, not transactions? And since
> > they have an assigned ID it means that the query is already executing
> > and we want to enable the tracking in another session, right?
>
> I think that was the idea.
Hi,
> This approach avoids the need to rewrite SQL or give special meaning to SQL
> comments.
SQLCommenter already has a good amount of support and is referenced in
opentelemetry https://github.com/open-telemetry/opentelemetry-sqlcommenter
So the goal was more to leverage the existing trace
Hi,
> Overall solution looks good for me except SQL Commenter - query
> instrumentation
> with SQL comments is often not possible on production systems. Instead
> the very often requested feature is to enable tracing for a given single
> query ID,
> or several (very limited number of) queries
Hi!
Overall solution looks good for me except SQL Commenter - query
instrumentation
with SQL comments is often not possible on production systems. Instead
the very often requested feature is to enable tracing for a given single
query ID,
or several (very limited number of) queries by IDs. It
Hi all
Just saw this thread.
I cooked up a PoC distributed tracing support in Pg years ago as part of
the 2ndQuadrant BDR project.
I used GUCs to set the `opentelemtery_trace_id` and
`opentelemetry_span_id`. These can be sent as protocol-level messages by
the client driver if the client driver
Hi,
Thanks for the updated patch!
> Some small changes, mostly around making tests less flaky:
> - Removed the top_span and nested_level in the span output, those were
> mostly used for debugging
> - More tests around Parse span in nested queries
> - Remove explicit queryId in the tests
```
+--
Hi,
On Thu, 12 Oct 2023 at 14:32, Anthonin Bonnefoy
wrote:
>
> Hi!
>
> I've made a new batch of changes and improvements.
> New features:
> - Triggers are now correctly supported. They were not correctly
> attached to the ExecutorFinish Span before.
> - Additional configuration: exporting
Hi!
Great you continue to work on this patch!
I'm checking out the newest changes.
On Fri, Sep 15, 2023 at 2:32 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi,
>
> > Renaming/Refactoring:
> > - All spans are now tracked in the palloced current_trace_spans buffer
> > compared to
Hi,
> Renaming/Refactoring:
> - All spans are now tracked in the palloced current_trace_spans buffer
> compared to top_span and parse_span being kept in a static variable
> before.
> - I've renamed query_spans to top_span. A top_span serves as the
> parent for all spans in a specific nested
Hi!
Storing spans is a tricky question. Monitoring systems often use pull model
and use probes or SQL
API for pulling data, so from this point of view it is much more convenient
to keep spans in separate
table. But in this case we come to another issue - how to flush this data
into the table?
Hi!
Thanks for the improvements!
>Here's a new patch with changes from the previous discussion:
>- I'm now directly storing nanoseconds duration in the span instead of the
instr_time. Using the instr_time macros was a bit awkward as the
durations I generate don't necessarily have a starting and
> What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT
and INSTR_TIME_GET_MILLISEC
> macros for timing calculations?
If you're talking of the two instances where I'm modifying the instr_time's
ticks, it's because I can't use the macros there.
The first case is for the parse
Hi!
What do you think about using INSTR_TIME_SET_CURRENT, INSTR_TIME_SUBTRACT
and INSTR_TIME_GET_MILLISEC
macros for timing calculations?
Also, have you thought about a way to trace existing (running) queries
without directly instrumenting them? It would
be much more usable for maintenance and
Hi,
> I'd keep Autotools build up to date
Definitely. The patch is still in a rough state and updating Autotools fell
through the cracks.
> I'm currently playing with the patch and
> reviewing sources, if you need any cooperation - please let us know.
The goal for me was to get validation on the
Hi,
I'd keep Autotools build up to date, because Meson is very limited in terms
of not very
up-to-date OS versions. Anyway, it's OK now. I'm currently playing with the
patch and
reviewing sources, if you need any cooperation - please let us know. I'm +1
for committing
this patch after review.
--
> Agree, something goes wrong when using Autotools (but not Meson) on
> both Linux and MacOS. I didn't investigate the issue though.
I was only using meson and forgot to keep Automake files up to date when
I've split pg_tracing.c in multiple files (span.c, explain.c...).
On Fri, Jul 28, 2023 at
Hi,
I've fixed the Autotools build, please check patch below (v2).
On Thu, Jul 27, 2023 at 6:39 PM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi,
>
> > Also FYI, there are build warnings because functions
> > const char * get_span_name(const Span * span, const char *qbuffer)
> >
Hi,
> Also FYI, there are build warnings because functions
> const char * get_span_name(const Span * span, const char *qbuffer)
> and
> const char * get_operation_name(const Span * span, const char *qbuffer)
> do not have default inside switch and no return outside of switch.
You are right,
Hi,
Also FYI, there are build warnings because functions
const char * get_span_name(const Span * span, const char *qbuffer)
and
const char * get_operation_name(const Span * span, const char *qbuffer)
do not have default inside switch and no return outside of switch.
--
Regards,
Nikita Malakhov
Hi!
I've tried to test the extension, but got errors calling make check and
cannot install the extension.
I've applied the patch onto current master and configured it as:
./configure --enable-debug --enable-cassert --enable-depend
--enable-tap-tests
Could you please advise if I'm doing something
I've initially thought of sending the spans from PostgreSQL since this is
the usual behavior of tracing libraries.
However, this created a lot potential issues:
- Protocol support and differences between trace collectors. OpenTelemetry
seems to use gRPC, others are using http and those will
Nikita,
> This patch looks very interesting, I'm working on the same subject too. But
> I've used
> another approach - I'm using C wrapper for C++ API library from
> OpenTelemetry, and
> handle span storage and output to this library. There are some nuances
> though, but it
> is possible. Have
Hi!
This patch looks very interesting, I'm working on the same subject too. But
I've used
another approach - I'm using C wrapper for C++ API library from
OpenTelemetry, and
handle span storage and output to this library. There are some nuances
though, but it
is possible. Have you tried to use
Hi Anthonin,
> I have a working prototype of a pg_tracing extension and wanted some feedback
> on the design and architecture.
The patch looks very interesting, thanks for working on it and for
sharing. The facts that the patch doesn't change the core except for
two lines in instrument.{c.h}
37 matches
Mail list logo
