zitadel/internal/eventstore/handler/v2/state_get.sql

SELECT
    aggregate_id
    , aggregate_type
    , "sequence"
    , event_date
    , "position"
    , filter_offset
FROM 
    projections.current_states
WHERE
    instance_id = $1
    AND projection_name = $2
FOR NO KEY UPDATE;
feat(eventstore): increase parallel write capabilities (#5940) This implementation increases parallel write capabilities of the eventstore. Please have a look at the technical advisories: [05](https://zitadel.com/docs/support/advisory/a10005) and [06](https://zitadel.com/docs/support/advisory/a10006). The implementation of eventstore.push is rewritten and stored events are migrated to a new table `eventstore.events2`. If you are using cockroach: make sure that the database user of ZITADEL has `VIEWACTIVITY` grant. This is used to query events. 2023-10-19 12:19:10 +02:00			`SELECT`
			`aggregate_id`
			`, aggregate_type`
			`, "sequence"`
			`, event_date`
			`, "position"`
fix(eventstore): improve pagination of handler filter (#6968) * fix(setup): add filter_offset to `projections.current_states` * fix(eventstore): allow offset in query * fix(handler): offset for already processed events (cherry picked from commit e3d1ca4d586f615854c05184c32314fbe67e128e) 2023-12-01 13:25:41 +01:00			`, filter_offset`
feat(eventstore): increase parallel write capabilities (#5940) This implementation increases parallel write capabilities of the eventstore. Please have a look at the technical advisories: [05](https://zitadel.com/docs/support/advisory/a10005) and [06](https://zitadel.com/docs/support/advisory/a10006). The implementation of eventstore.push is rewritten and stored events are migrated to a new table `eventstore.events2`. If you are using cockroach: make sure that the database user of ZITADEL has `VIEWACTIVITY` grant. This is used to query events. 2023-10-19 12:19:10 +02:00			`FROM`
			`projections.current_states`
			`WHERE`
			`instance_id = $1`
			`AND projection_name = $2`
fix(projections): overhaul the event projection system (#10560) This PR overhauls our event projection system to make it more robust and prevent skipped events under high load. The core change replaces our custom, transaction-based locking with standard PostgreSQL advisory locks. We also introduce a worker pool to manage concurrency and prevent database connection exhaustion. ### Key Changes * Advisory Locks for Projections: Replaces exclusive row locks and inspection of `pg_stat_activity` with PostgreSQL advisory locks for managing projection state. This is a more reliable and standard approach to distributed locking. * Simplified Await Logic: Removes the complex logic for awaiting open transactions, simplifying it to a more straightforward time-based filtering of events. * Projection Worker Pool: Implements a worker pool to limit concurrent projection triggers, preventing connection exhaustion and improving stability under load. A new `MaxParallelTriggers` configuration option is introduced. ### Problem Solved Under high throughput, a race condition could cause projections to miss events from the eventstore. This led to inconsistent data in projection tables (e.g., a user grant might be missing). This PR fixes the underlying locking and concurrency issues to ensure all events are processed reliably. ### How it Works 1. Event Writing: When writing events, a shared advisory lock is taken. This signals that a write is in progress. 2. Event Handling (Projections): * A projection worker attempts to acquire an exclusive advisory lock for that specific projection. If the lock is already held, it means another worker is on the job, so the current one backs off. * Once the lock is acquired, the worker briefly acquires and releases the same shared lock used by event writers. This acts as a barrier, ensuring it waits for any in-flight writes to complete. * Finally, it processes all events that occurred before its transaction began. ### Additional Information * ZITADEL no longer modifies the `application_name` PostgreSQL variable during event writes. * The lock on the `current_states` table is now `FOR NO KEY UPDATE`. * Fixes https://github.com/zitadel/zitadel/issues/8509 --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Tim Möhlmann <tim+github@zitadel.com> (cherry picked from commit 0575f67e942c3192b36e39fd6ae06b1502bc0f5f) 2025-09-03 17:29:00 +02:00			`FOR NO KEY UPDATE;`