You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 2, 2024. It is now read-only.
Previoussly there was a deadlock in get_series_id functions
because the get_or_create_metric_table_name call may take
an exclusive lock on the series table but the startup of
the sql function took an access lock on that same table because
SQL functions parse/plan all statements in the function before
executing any. Thus, even though get_or_create_metric_table_name
was executed before any series table access, the lock was already taken.
This lock escalation caused a deadlock because the insert on the
metric table has an ON CONFLICT DO NOTHING and thus a waiting
process may wait on a winning process to complete while holding
an access lock on the series table, but the winning
process needs an exclusive lock on the series table.
Switching to a PLPGSQL function helps because locks are
taken in order of execution and so there is no lock escalation.
We also added complete ingest concurrency tests to try
to catch this in the future.
Finally, we ran benchmark tests and it seems that the switch to
PLPGSQL does not significantly degrade performance.
err:=db.QueryRow(context.Background(), "SELECT _prom_catalog.create_series((SELECT id FROM _prom_catalog.metric WHERE metric_name=$3), $1, array[(SELECT id FROM _prom_catalog.label WHERE key = '__name__' AND value=$3), $2::int])",
0 commit comments