Striim MDR on PostgreSQL: Fixing striimsecuritytable does not exist

When you test software for a living, it helps to have more than one environment to work with. Right now I have Striim 5.4.2 and Striim 5.4.4 running side by side. Not much difference between the versions, but it’s still handy to have both around.

The nice part is that both use PostgreSQL 18 for the metadata repository (MDR), each in its own database on the same PostgreSQL instance. The 5.4.2 repository went in without a problem. The 5.4.4 repository was a bit of a hassle. That wasn’t because of the version. It was because of how I configured it. Hopefully this post saves you some time if you’re building a new MDR on PostgreSQL.

Tested on: Striim 5.4.4 (alongside 5.4.2), PostgreSQL 18, macOS.

What the MDR Does

Quick refresher: the MDR is where Striim keeps its application definitions, checkpoints, and recovery state. Out of the box it runs on a bundled Derby instance. I walked through moving it to PostgreSQL in So, You Want to Move Your Striim MDR to PostgreSQL?. If Striim can’t use its repository, it doesn’t start. Simple as that.

The Documented Setup

Building a PostgreSQL repository happens in two passes. First, log in to PostgreSQL as an administrator and create the user and the database, then grant access:

create user striim with password '<password>';
create database striimrepo;
grant all on database striimrepo to striim;

Next, log in to the new repository database as the striim user, create the schema, and set the search path:

create schema striim;
alter role striim set search_path to striim;

Finally, still as striim, run the two define scripts that ship in Striim’s conf directory:

psql -U striim -d striimrepo -f DefineMetadataReposPostgres.sql
psql -U striim -d striimrepo -f DefineMeteringReposPostgres.sql

Follow those steps and you should have a working repository. On my 5.4.2 setup, it worked without a problem.

How I Ran Into It

For 5.4.4, I created a second database on the same PostgreSQL instance, striimrepo544, and left the owner as postgres. Then I logged in to striimrepo544 and ran the define scripts, DefineMetadataReposPostgres.sql and DefineMeteringReposPostgres.sql. Both completed. Done, I thought.

When I started Striim 5.4.4 against the new MDR, this is all I got:

$ ./server.sh
2026-10-16T17:00:55.396537-04:00[America/New_York] Starting Striim Server - Version 5.4.4.0 (7f672747fd)
WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
WARNING: sun.misc.Unsafe::objectFieldOffset has been called by org.jctools.util.UnsafeAccess (file:/Users/<user>/Striim_5.4.4/Striim/lib/jctools-core-4.0.5.jar)
WARNING: Please consider reporting this to the maintainers of class org.jctools.util.UnsafeAccess
WARNING: sun.misc.Unsafe::objectFieldOffset will be removed in a future release
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by com.sun.jna.Native in an unnamed module (file:/Users/<user>/Striim_5.4.4/Striim/lib/jna-5.12.1.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

Striim Server Beginning Shutdown

The WARNING lines are Java runtime noise. The last line is the only one that matters, and it doesn’t say why. Off to the server log, which had the real error. The server couldn’t find the security table in the MDR:

Caused by: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.7.16.v20250613-47773a333b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: ERROR: relation "striimsecuritytable" does not exist

Why the Error Is Misleading

A missing table? The define scripts had just run. Everything was set up correctly.

Not quite.

Remember that “as the striim user” bit from the documented setup? I skipped it. Because I did the work as postgres, I ended up with a database where everything was owned by postgres, including the striim schema. The repository was there. It just belonged to the wrong user. And the error points you at a missing table instead of at ownership.

Finding the Real Problem

This query shows who owns the striim schema:

SELECT nspname, pg_get_userbyid(nspowner) AS owner
FROM pg_namespace
WHERE nspname = 'striim';

nspname|owner   |
-------+--------+
striim |postgres|

There it is. The schema is owned by postgres, not striim.

The Fix

Both of these steps run as postgres while connected to striimrepo544. First, hand the schema over to striim:

ALTER SCHEMA striim OWNER TO striim;

Rerun the ownership query to confirm the change:

nspname|owner |
-------+------+
striim |striim|

The schema is only half of it. The objects inside it were still owned by postgres, so the last step is to change ownership on everything in the schema:

DO $$
DECLARE
  r record;
BEGIN
  FOR r IN
    SELECT c.relname, c.relkind
    FROM pg_class c
    JOIN pg_namespace n ON n.oid = c.relnamespace
    WHERE n.nspname = 'striim'
      AND c.relkind IN ('r','p','v','m','S','f')
      -- skip sequences tied to a table column; they move with their table
      AND NOT (c.relkind = 'S' AND EXISTS (
            SELECT 1 FROM pg_depend d
            WHERE d.objid = c.oid
              AND d.classid = 'pg_class'::regclass
              AND d.deptype IN ('a','i')))
  LOOP
    EXECUTE format('ALTER %s striim.%I OWNER TO striim',
      CASE r.relkind
        WHEN 'v' THEN 'VIEW'
        WHEN 'm' THEN 'MATERIALIZED VIEW'
        WHEN 'S' THEN 'SEQUENCE'
        WHEN 'f' THEN 'FOREIGN TABLE'
        ELSE 'TABLE'
      END,
      r.relname);
  END LOOP;
END $$;

The block walks pg_class for everything in the striim schema and issues an ALTER ... OWNER TO striim for each table, partitioned table, view, materialized view, sequence, and foreign table. Sequences tied to a table column are skipped because they move with their table.

Verify Before You Restart

Before starting Striim again, confirm nothing in the schema is still owned by someone else:

SELECT c.relname, c.relkind, pg_get_userbyid(c.relowner) AS owner
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'striim'
  AND pg_get_userbyid(c.relowner) <> 'striim';

No rows back means you’re good. Once everything was owned by striim, the 5.4.4 server started against the new MDR and gave me the URL to open the console.

A Word of Caution

I did this on a brand-new, empty lab repository. If you find yourself changing ownership on an MDR that is already backing running applications, take a backup and test the change outside production first.

Takeaways

• Create the schema and run the define scripts while connected as the striim user, as the documentation says. Do that and you shouldn’t see this.
• If you built the repository as postgres, move ownership of the striim schema and everything in it to striim before starting the server.
• When Striim prints Striim Server Beginning Shutdown with no reason, the answer is in the server log.
• relation "striimsecuritytable" does not exist doesn’t mean the define scripts failed. Check ownership first.
• Running multiple Striim versions against one PostgreSQL instance works fine. Give each version its own database and check ownership on each one.

For the full setup reference, see Configuring Striim’s metadata repository in the Striim documentation.

Enjoy!

Please follow and like: