diff --git a/docs/guide/durability/marten/subscriptions.md b/docs/guide/durability/marten/subscriptions.md
index bd750a408..c5cd88f8e 100644
--- a/docs/guide/durability/marten/subscriptions.md
+++ b/docs/guide/durability/marten/subscriptions.md
@@ -1,4 +1,4 @@
-# Event Subscriptions
+# Event Subscriptions
::: tip
The older [Event Forwarding](./event-forwarding) feature is a subset of subscriptions, but happens at the time of event
@@ -6,7 +6,7 @@ capture whereas the event subscriptions are processed in strict order in a backg
subsystem. The **strong suggestion from the Wolverine team is to use one or the other approach, but not both in the same system**.
:::
-New in Wolverine 2.2 is the ability to subscribe to Marten events to carry out message processing by Wolverine on
+Wolverine has the ability to extend Marten's [event subscription functionality]() to carry out message processing by Wolverine on
the events being captured by Marten in strict order. This new functionality works through Marten's [async daemon](https://martendb.io/events/projections/async-daemon.html)
There are easy recipes for processing events through Wolverine message handlers, and also for just publishing events
diff --git a/docs/guide/durability/postgresql.md b/docs/guide/durability/postgresql.md
index 28c163fe4..9524fc9a1 100644
--- a/docs/guide/durability/postgresql.md
+++ b/docs/guide/durability/postgresql.md
@@ -60,40 +60,6 @@ use this option which *also* activates PostgreSQL backed message persistence:
```cs
-using var host = await Host.CreateDefaultBuilder()
- .UseWolverine((context, opts) =>
- {
- var connectionString = context.Configuration.GetConnectionString("sqlserver");
- opts.UseSqlServerPersistenceAndTransport(connectionString, "myapp")
-
- // Tell Wolverine to build out all necessary queue or scheduled message
- // tables on demand as needed
- .AutoProvision()
-
- // Optional that may be helpful in testing, but probably bad
- // in production!
- .AutoPurgeOnStartup();
-
- // Use this extension method to create subscriber rules
- opts.PublishAllMessages().ToSqlServerQueue("outbound");
-
- // Use this to set up queue listeners
- opts.ListenToSqlServerQueue("inbound")
-
- .CircuitBreaker(cb =>
- {
- // fine tune the circuit breaker
- // policies here
- })
-
- // Optionally specify how many messages to
- // fetch into the listener at any one time
- .MaximumMessagesToReceive(50);
- }).StartAsync();
-```
-snippet source | anchor
-
-```cs
using var host = await Host.CreateDefaultBuilder()
.UseWolverine((context, opts) =>
{
@@ -125,18 +91,18 @@ using var host = await Host.CreateDefaultBuilder()
.MaximumMessagesToReceive(50);
}).StartAsync();
```
-snippet source | anchor
+snippet source | anchor
The PostgreSQL transport is strictly queue-based at this point. The queues are configured as durable by default, meaning
that they are utilizing the transactional inbox and outbox. The PostgreSQL queues can also be buffered:
-
-
+
+
```cs
-opts.ListenToSqlServerQueue("sender").BufferedInMemory();
+opts.ListenToPostgresqlQueue("sender").BufferedInMemory();
```
-snippet source | anchor
+snippet source | anchor
Using this option just means that the PostgreSQL queues can be used for both sending or receiving with no integration
diff --git a/src/Persistence/PersistenceTests/Postgresql/Transport/DocumentationSamples.cs b/src/Persistence/PersistenceTests/Postgresql/Transport/DocumentationSamples.cs
index 327c24aca..90a813e3f 100644
--- a/src/Persistence/PersistenceTests/Postgresql/Transport/DocumentationSamples.cs
+++ b/src/Persistence/PersistenceTests/Postgresql/Transport/DocumentationSamples.cs
@@ -9,7 +9,7 @@ public class DocumentationSamples
{
public static async Task Bootstrapping()
{
- #region sample_using_postgres_transport
+ #region sample_using_sqlserver_transport
using var host = await Host.CreateDefaultBuilder()
.UseWolverine((context, opts) =>