Postgres advisory lock path emits SET LOCAL outside a transaction, causing PostgreSQL warnings

[Meryovi]

We are seeing repeated PostgreSQL warnings when running Marten async daemon in HotCold mode across multiple application hosts.

Observed PostgreSQL warning:

WARNING: SET LOCAL can only be used in transaction blocks

Sample:

2026-03-23 14:07:43.867 UTC [946] WARNING:  SET LOCAL can only be used in transaction blocks
2026-03-23 14:07:44.101 UTC [949] WARNING:  SET LOCAL can only be used in transaction blocks
2026-03-23 14:07:48.890 UTC [946] WARNING:  SET LOCAL can only be used in transaction blocks
2026-03-23 14:07:49.163 UTC [949] WARNING:  SET LOCAL can only be used in transaction blocks
2026-03-23 14:07:53.911 UTC [946] WARNING:  SET LOCAL can only be used in transaction blocks
2026-03-23 14:07:54.188 UTC [949] WARNING:  SET LOCAL can only be used in transaction blocks

With additional Npgsql command logging enabled, the nearby statements are:

select last_value from shared.mt_events_sequence;
select last_seq_id, last_updated, transaction_timestamp() as timestamp
from shared.mt_event_progression
where name = 'HighWaterMark';

and then:

SET LOCAL statement_timeout = 0;
SET LOCAL lock_timeout = 0;
SELECT pg_catalog.pg_try_advisory_lock($1) AS result;

This appears to come from the Postgres advisory lock acquisition path used for daemon coordination.

Why this matters:

It produces repeated WARNING entries in PostgreSQL logs
It can create concern that a transaction boundary is broken or that something is misbehaving
In environments with centralized database log monitoring, this looks like an application problem even though behavior seems otherwise functional

Expectation:

Either this path should avoid SET LOCAL when not operating inside a transaction if possible
Or the implementation should use a transactional path if SET LOCAL is required
At minimum, it would be good to know whether this is intended behavior

Environment:

Marten 8.26.0
HotCold async daemon mode
Multiple application hosts active at the same time
PostgreSQL 18 with warning log level enabled

[jeremydmiller]

@Meryovi Try setting StoreOptions.UseMonitoredAdvisoryLock = false; to use the older, Marten version of AdvisoryLock. I'm moving this to a discussion. Some people run into trouble w/ the 3rd party lib, and most don't. We have no idea why yet.