I've just tried that on my Intel Mac and still getting this error:

dyld[53257]: Library not loaded: /usr/local/opt/zstd/lib/libzstd.1.dylib
  Referenced from: <35902E26-B869-3DC7-B6B6-33EC07E5D999> /Users/inikolaev/.codon/lib/codon/libcodonc.dylib
  Reason: tried: '/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/usr/local/opt/zstd/lib/libzstd.1.dylib' (no such file), '/usr/local/lib/libzstd.1.dylib' (no such file), '/usr/lib/libzstd.1.dylib' (no such file, not in dyld cache)

Has this been fixed yet?

So I guess I should either try another PostgreSQL base image or build pg_cron from source.

That explains why I managed to make it work with PostgreSQL 15, though I still had to make some adjustments:

RUN apk add --no-cache postgresql-pg_cron sudo \
    && cp /usr/lib/postgresql15/pg_cron.so /usr/local/lib/postgresql/ \
    && cp /usr/share/postgresql/extension/* /usr/local/share/postgresql/extension

Was just looking for exactly this feature - I would like to be able to start a database container, but I need it to have some additional extensions to be installed first.

The beauty of test containers is that I don't need to build anything else prior to starting my tests - I start them and it just works. But if this is not supported then I have to come up with some fixture that does that for me, perhaps using the provided docker client.

Does this package work or am I missing some extra steps to set it up? Here's my Dockerfile:

FROM public.ecr.aws/docker/library/postgres:13-alpine

RUN apk add postgresql-pg_cron

CMD ["-c", "shared_preload_libraries=pg_cron", "-c", "cron.database_name=postgres", "-c", "log_statement=all"]

But when container is started I'm getting the following error:

PostgreSQL Database directory appears to contain a database; Skipping initialization

2022-12-19 10:17:20.827 UTC [97] FATAL:  could not access file "pg_cron": No such file or directory
2022-12-19 10:17:20.827 UTC [97] LOG:  database system is shut down

The pg_cron.so is installed /usr/lib/postgresql14/pg_cron.so:

-rwxr-xr-x    1 root     root         71792 Nov 12  2021 pg_cron.so
-rwxr-xr-x    1 root     root         22192 Aug 15 00:19 pgoutput.so
-rwxr-xr-x    1 root     root        198400 Aug 15 00:19 plpgsql.so

pg_cron.control is present at /usr/share/postgresql14/extension/pg_cron.control along with .sql files:

comment = 'Job scheduler for PostgreSQL'
default_version = '1.4'
module_pathname = '$libdir/pg_cron'
relocatable = false

@majorgreys I haven't really tried to downgrade and unfortunately I don't have a reproducer.

For me it's a bit counter intuitive why would span be missing, even when distributed tracing is involved. Could you please explain why this is the case at all or maybe there some documentation that would explain this?

The kind of code I have looks like this:

@trace()
def some_function():
    s = span()
    s.set_tags({})
    
def trace():
    def trace_decorator(f):
        span_name = name if name else f"{f.__module__}.{f.__name__}"
       
        @functools.wraps(f)
        async def func_wrapper(*args, **kwargs):
            with tracer.trace(span_name, service=service, resource=resource, span_type=span_type):
                return await f(*args, **kwargs)

        return func_wrapper
    return trace_decorator

def span():
    return trace.current_span()  # This may return None sporadically

From my point of view span must always exist in such case or a new span should have been created.

When I look at successful and failing traces in DataDog - I don't really spot any difference - I see the trace beginning from the calling service all the way to my service.

Summary of problem

After upgrade from 1.5.3 to 1.6.0 we started to see an increased number of cases when trace.current_span() returns None. I'm not entirely sure why and whether it's related to the upgrade at all, as I haven't tried to downgrade, but the question is what would we do in such cases?

The documentation mentions this

Note that there may be an active span represented by a context object (like from a distributed trace) which will not be returned by this method.

But if that's the case, what is the right way to handle it and set tags on current span?

The method where trace.current_span() is being called is decorated with wrap - does it guarantee to create a new span at all times or there cases when span is not created?

I would like to have a method that always returns a span, so that I could set tags on it.