超时
Extend database timeouts to execute longer transactions
仪表板和客户端查询的最大可配置超时时间为60秒。对于更长的交易,请使用Supavisor或直接连接。
🌐 Dashboard and Client queries have a max-configurable timeout of 60 seconds. For longer transactions, use Supavisor or direct connections.
更改 Postgres 超时 #
🌐 Change Postgres timeout
你可以在以下位置更改 Postgres 的超时:
🌐 You can change the Postgres timeout at the:
会话级别 #
🌐 Session level
会话级别的设置只会在连接期间有效。
🌐 Session level settings persist only for the duration of the connection.
通过运行以下命令设置会话超时:
🌐 Set the session timeout by running:
1set statement_timeout = '10min';因为它只适用于会话,所以只能用于通过 Supavisor 在会话模式(端口 5432)下的连接或直接连接。不能在仪表板中使用,也不能与 Supabase 客户端 API 一起使用,也不能在 Supavisor 的事务模式(端口 6543)下使用。
🌐 Because it applies to sessions only, it can only be used with connections through Supavisor in session mode (port 5432) or a direct connection. It cannot be used in the Dashboard, with the Supabase Client API, nor with Supavisor in Transaction mode (port 6543).
这通常用于单个、长时间运行的管理任务,例如创建 HSNW 索引。设置实现后,你可以通过执行以下操作来查看它:
🌐 This is most often used for single, long running, administrative tasks, such as creating an HSNW index. Once the setting is implemented, you can view it by executing:
1SHOW statement_timeout;查看关于更改会话超时的完整指南。
🌐 See the full guide on changing session timeouts.
功能级别 #
🌐 Function level
当从 Supabase 客户端库调用时,这个方法适用于数据库 REST API:
🌐 This works with the Database REST API when called from the Supabase client libraries:
1create or replace function myfunc()2returns void as $$3 select pg_sleep(3); -- simulating some long-running process4$$5language sql6set statement_timeout TO '4s'; -- set custom timeout这主要是针对那些需要对运行时间有特别豁免的重复功能。
🌐 This is mostly for recurring functions that need a special exemption for runtimes.
角色等级 #
🌐 Role level
这设置了特定角色的超时时间。
🌐 This sets the timeout for a specific role.
默认的角色超时时间是:
🌐 The default role timeouts are:
anon:3sauthenticated:8sservice_role:无(如果未设置,则默认为authenticator角色的 8 秒超时)postgres:无(默认全局超时限制为2分钟)
运行以下查询来更改角色的超时设置:
🌐 Run the following query to change a role's timeout:
1alter role example_role set statement_timeout = '10min'; -- could also use seconds '10s'如果你要更改 Supabase 客户端 API 调用的超时时间,你需要通过运行以下脚本重新加载 PostgREST,以反映超时更改:
🌐 If you are changing the timeout for the Supabase Client API calls, you will need to reload PostgREST to reflect the timeout changes by running the following script:
1NOTIFY pgrst, 'reload config';与全局设置不同,结果无法通过 SHOW statement_timeout 检查。相反,请运行:
🌐 Unlike global settings, the result cannot be checked with SHOW statement_timeout. Instead, run:
1select2 rolname,3 rolconfig4from pg_roles5where6 rolname in (7 'anon',8 'authenticated',9 'postgres',10 'service_role'11 -- ,<ANY CUSTOM ROLES>12 );全球水平 #
🌐 Global level
这会更改所有角色和会话的语句超时,前提是它们还没有设置明确的超时。
🌐 This changes the statement timeout for all roles and sessions without an explicit timeout already set.
1alter database postgres set statement_timeout TO '4s';检查你的更改是否生效:
🌐 Check if your changes took effect:
1show statement_timeout;虽然不是必须的,但如果你不确定是否已设置超时,你可以进行一个快速测试:
🌐 Although not necessary, if you are uncertain if a timeout has been applied, you can run a quick test:
1create or replace function myfunc()2returns void as $$3 select pg_sleep(601); -- simulating some long-running process4$$5language sql;识别超时 #
🌐 Identifying timeouts
Supabase 控制台包含一些工具,可以帮助你识别超时和运行时间较长的查询。
🌐 The Supabase Dashboard contains tools to help you identify timed-out and long-running queries.
使用日志浏览器 #
🌐 Using the Logs Explorer
进入 日志浏览器,运行以下查询来识别超时事件(statement timeout)以及成功运行超过 10 秒的查询(duration)。
🌐 Go to the Logs Explorer, and run the following query to identify timed-out events (statement timeout) and queries that successfully run for longer than 10 seconds (duration).
1select2 cast(postgres_logs.timestamp as datetime) as timestamp,3 event_message,4 parsed.error_severity,5 parsed.user_name,6 parsed.query,7 parsed.detail,8 parsed.hint,9 parsed.sql_state_code,10 parsed.backend_type11from12 postgres_logs13 cross join unnest(metadata) as metadata14 cross join unnest(metadata.parsed) as parsed15where16 regexp_contains(event_message, 'duration|statement timeout')17 -- (OPTIONAL) MODIFY OR REMOVE18 and parsed.user_name = 'authenticator' -- <--------CHANGE19order by timestamp desc20limit 100;使用查询性能页面 #
🌐 Using the Query Performance page
访问查询性能页面,并按相关角色和查询速度进行筛选。这只会识别运行缓慢但成功的查询。与日志浏览器不同,它不会显示超时的查询。
🌐 Go to the Query Performance page and filter by relevant role and query speeds. This only identifies slow-running but successful queries. Unlike the Log Explorer, it does not show you timed-out queries.
理解日志中的角色 #
🌐 Understanding roles in logs
每个 API 服务器都使用一个指定的用户来连接数据库:
🌐 Each API server uses a designated user for connecting to the database:
| 角色 | API/工具 |
|---|---|
supabase_admin | 由 Realtime 使用以及用于项目配置 |
authenticator | PostgREST |
supabase_auth_admin | 认证 |
supabase_storage_admin | 存储 |
supabase_replication_admin | 同步只读副本 |
postgres | Supabase 仪表板和外部工具(例如 Prisma、SQLAlchemy、PSQL...) |
| 自定义角色 | 外部工具(例如 Prisma、SQLAlchemy、PSQL...) |
通过 parsed.user_name 字段筛选,只获取特定用户的日志:
🌐 Filter by the parsed.user_name field to only retrieve logs made by specific users:
1-- find events based on role/server2... query3where4 -- find events from the relevant role5 parsed.user_name = '<ROLE>'