Prompt

On a Linux system, I have an application A that initiates a transaction in a PostgreSQL database. It creates some state inside that transaction. I want to work with that uncommitted state from some other application, B, on the same Linux system as where A is running. I can change the source code of both A and B. Is this possible?

Response

Yes, but not in the way most people initially expect.

In PostgreSQL, uncommitted changes made in one transaction are normally visible only to that transaction. A separate database connection—even from another application on the same machine—cannot see those changes under PostgreSQL’s MVCC model. PostgreSQL does not support dirty reads, even at the SQL standard’s READ UNCOMMITTED isolation level (it behaves like READ COMMITTED).

However, there are several ways to achieve something similar, depending on what you actually need.

Option 1: Share the same database connection/transaction

If application B can somehow execute SQL through the exact same PostgreSQL session and transaction that A started, then B can see the uncommitted state.

For example:

  • A opens a PostgreSQL connection.
  • A begins a transaction.
  • A creates temporary state.
  • B sends requests to A (IPC, socket, shared memory, RPC, etc.).
  • A executes B’s SQL on the same connection and returns results.

This is the only way for B to directly operate on the same transactional view of the database.

Option 2: Move A and B into a single service

Instead of two independent PostgreSQL clients:

B -> A -> PostgreSQL

A owns the transaction and exposes an API to B.

This is often the cleanest architecture when both components need to cooperate on uncommitted data.

Option 3: Export a snapshot (read-only visibility)

PostgreSQL supports snapshot export/import:

SELECT pg_export_snapshot();

Another transaction can import that snapshot:

SET TRANSACTION SNAPSHOT '...';

But this only allows another transaction to see the same committed database snapshot. It does not expose A’s own uncommitted writes.

Therefore it does not solve your problem if B must see rows inserted or modified by A that have not yet been committed.

Option 4: Store shared state outside PostgreSQL

If the purpose is cooperative processing before commit, A can write the intermediate state to:

  • shared memory (shm_open, POSIX shared memory)
  • a Unix domain socket
  • a temporary file
  • a separate cache such as Redis

and later persist the final result to PostgreSQL.

Option 5: Use a second connection with a different design

Sometimes people want:

A:
BEGIN;
INSERT ...;

B:
SELECT ...

before commit.

In PostgreSQL, this is simply impossible. No isolation level or configuration setting will let B see A’s uncommitted table modifications.

Less common possibility: B runs inside PostgreSQL

If B can be implemented as:

  • a stored procedure,
  • a function,
  • an extension,

and A invokes it within the same transaction, then B naturally sees the uncommitted state because it is executing inside the transaction context.

Bottom line

If A and B are separate applications with separate PostgreSQL connections, B cannot see A’s uncommitted changes. To work with that state, either:

  1. Have B execute through A’s connection/transaction.
  2. Merge the logic into one service/process.
  3. Share the intermediate state outside PostgreSQL.
  4. Run B’s logic inside PostgreSQL within A’s transaction.

The best solution depends on whether B needs to read the uncommitted state, modify it, or perform arbitrary SQL against it.