# Postgresql-vergrendelingen bij hoog gelijktijdig API-sleutelgebruik

**URL:** https://meta.discourse.org/t/postgresql-locks-with-high-concurrency-api-key-usage/318383
**Category:** Self-hosting
**Created:** [25 juli 2024 om 15:09 UTC](https://meta.discourse.org/t/postgresql-locks-with-high-concurrency-api-key-usage/318383 "2024-07-25T15:09:48Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![Joan\_Tomàs\_i\_Buliart](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/joan_tom%C3%A0s_i_buliart/32/325368_2.png) [@Joan\_Tomàs\_i\_Buliart](https://meta.discourse.org/u/Joan_Tom%C3%A0s_i_Buliart)
#### Post date: [25 juli 2024 om 15:09 UTC](https://meta.discourse.org/t/postgresql-locks-with-high-concurrency-api-key-usage/318383/1 "2024-07-25T15:09:48Z")

</div>

Hello Community,

We are using the Discourse API on a self-hosted installation. Our use case is quite intensive in terms of concurrency, with around 100 API requests per second on average. We are also using PostgreSQL+Patroni+HAProxy to provide a high-availability database setup. Occasionally, our PostgreSQL locks and Patroni restarts the master node.

We have implemented a cron job to check for blocked transactions, and every time this issue occurs, we find the same kind of operations:

```plaintext
 blocked_pid | blocked_user | blocking_pid | blocking_user | blocked_statement | current_statement_in_blocking_process                              
-------------+--------------+--------------+---------------+------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------
      297904 | discourse | 293083 | discourse | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:38:16.822352' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
      296718 | discourse | 293083 | discourse | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:50.900480' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21
      293101 | discourse | 293083 | discourse | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:49.485074' WHERE "api_keys"."id" = 21 | UPDATE "api_keys" SET "last_used_at" = '2024-07-16 16:34:48.163449' WHERE "api_keys"."id" = 21

```

As you can see, many requests are trying to update the last usage time of the same API key.

For now, we have increased the number of API keys that our application is using to reduce the probability of collision. I noticed that there is code in place that checks if the API key was modified in the last minute to avoid an update. However, I assume that since we are using more than one pod to process the requests, this protection is not effective.

I am unsure if we should report this as a bug or if there are any parameters to avoid this kind of collision (either in Discourse or PostgreSQL). Note that for us, the information related to the last usage is relevant, but a resolution of 1 day would be sufficient.

I would also like to know what the preferred approach is to manage PostgreSQL HA with auto recovery.

Thanks

---

<div class="post-metadata">

### Author: ![Joan\_Tomàs\_i\_Buliart](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/joan_tom%C3%A0s_i_buliart/32/325368_2.png) [@Joan\_Tomàs\_i\_Buliart](https://meta.discourse.org/u/Joan_Tom%C3%A0s_i_Buliart)
#### Post date: [2 september 2024 om 07:50 UTC](https://meta.discourse.org/t/postgresql-locks-with-high-concurrency-api-key-usage/318383/2 "2024-09-02T07:50:07Z")

</div>

Has anyone encountered a similar issue or can provide some guidance on what to investigate? Could it be possible that Discourse is not designed to handle this volume of requests per second?

Thank you in advance.