migrate(docs): troubleshooting 9 (#30937)
* migrate(docs): troubleshooting 9 timeouts, latency * light updates * Update NavigationMenu.constants.ts * Update canceling-statement-due-to-statement-timeout-581wFv.mdx Added keyword * Apply suggestions from code review --------- Co-authored-by: Brian Brennglass <brian@Brians-MacBook-Pro.local> Co-authored-by: TheOtherBrian1 <91111415+TheOtherBrian1@users.noreply.github.com> Co-authored-by: Kevin Brolly <kevin.brolly@supabase.io>
This commit is contained in:
Charis
GitHub
@@ -9,13 +9,12 @@ apps/**/out
|
||||
apps/www/schema.sql
|
||||
apps/www/public/images/*
|
||||
apps/docs/**/generated/*
|
||||
apps/docs/examples
|
||||
examples/slack-clone/nextjs-slack-clone/full-schema.sql
|
||||
# ignore files with custom js formatting
|
||||
apps/docs/pages/guides/auth/*.mdx
|
||||
apps/docs/pages/guides/integrations/*.mdx
|
||||
apps/studio/public
|
||||
apps/**/.turbo
|
||||
apps/docs/CONTRIBUTING.md
|
||||
apps/design-system/__registry__
|
||||
packages/icons/__registry__
|
||||
packages/icons/src/icons/*.ts
|
||||
packages/icons/src/icons/*.ts
|
||||
|
||||
@@ -212,7 +212,8 @@ export const GLOBAL_MENU_ITEMS: GlobalMenuItems = [
|
||||
label: 'Resources',
|
||||
menuItems: [
|
||||
[
|
||||
/* {
|
||||
/*
|
||||
{
|
||||
label: 'Troubleshooting',
|
||||
icon: 'contributing',
|
||||
href: '/guides/troubleshooting',
|
||||
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title = "Avoiding timeouts in long running queries"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/21133"
|
||||
date_created = "2024-02-09T02:46:42+00:00"
|
||||
topics = ["database", "platform"]
|
||||
keywords = ["timeout", "query", "database", "psql", "compute"]
|
||||
---
|
||||
|
||||
<Admonition type="tip">
|
||||
|
||||
This page covers long-running queries via the Dashboard or external interfaces. For Supabase Client API timeout errors, check this [guide](https://github.com/orgs/supabase/discussions/14256) instead.
|
||||
|
||||
</Admonition>
|
||||
|
||||
Certain queries, like indexing a table or changing a column's data type, are inherently time-consuming. The [Dashboard's SQL Editor](https://supabase.com/dashboard/project/_/sql/) has a 1-minute timeout limit.
|
||||
|
||||
To execute long-running queries, follow the below steps.
|
||||
|
||||
### Install an external SQL client
|
||||
|
||||
The guide focuses on [psql](https://supabase.com/docs/guides/database/psql) but you can use any Postgres client.
|
||||
|
||||
Some other options include:
|
||||
|
||||
- [pgadmin](https://supabase.com/docs/guides/database/pgadmin)
|
||||
- [DBeaver](https://supabase.com/docs/guides/database/dbeaver)
|
||||
|
||||
You can install PSQL in [macOS](https://stackoverflow.com/a/49689589/2188186) and [Windows](https://www.postgresql.org/download/windows/) by following these links and instructions. For Linux (Debian) you can run the following:
|
||||
|
||||
```bash
|
||||
sudo apt-get update
|
||||
sudo apt-get install postgresql-client
|
||||
```
|
||||
|
||||
Once installed, you can find your PSQL string in the [Database Settings](https://supabase.com/dashboard/project/_/settings/database). Please make sure if you are using the pooler connection that it is in session mode (port 5432).
|
||||
|
||||
<Admonition type="tip">
|
||||
|
||||
If you are working in an [IPv6 environment](https://github.com/orgs/supabase/discussions/27034) or have the IPv4 Add-On, it is preferable to use the direct connection.
|
||||
|
||||
</Admonition>
|
||||
|
||||
### Increase the query timeout
|
||||
|
||||
Then you can increase the query timeout solely for your session:
|
||||
|
||||
Long timeout
|
||||
|
||||
```sql
|
||||
set statement_timeout = '120min';
|
||||
```
|
||||
|
||||
Disable timeout
|
||||
|
||||
```sql
|
||||
set statement_timeout = '0';
|
||||
```
|
||||
|
||||
If your task is particularly long, you can may want to consider boosting your computing power temporarily. Compute size on Supabase is charged by the hour, so you can increase it for an hour or two, complete your task faster, then scale it back afterward.
|
||||
|
||||
If you want to temporarily upgrade, you can find the add-ons for your project in your [Dashboard's Add-Ons Settings.](https://supabase.green/dashboard/project/_/settings/addons)
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title = 'Canceling statement due to "statement timeout"'
|
||||
github_url = "https://github.com/orgs/supabase/discussions/14256"
|
||||
date_created = "2023-05-10T08:29:05+00:00"
|
||||
topics = ["database"]
|
||||
keywords = ["statement", "timeout", "postgres", "performance"]
|
||||
---
|
||||
|
||||
> If encountering 504 or timeout errors in the Dashboard, check out this [guide](https://github.com/orgs/supabase/discussions/21133#discussioncomment-9573776)
|
||||
|
||||
You can run this query to check the current settings set for your roles: `SELECT rolname, rolconfig FROM pg_roles;`
|
||||
|
||||
To increase the `statement_timeout` for a specific role, you may follow the instructions [here](https://supabase.com/docs/guides/database/timeouts#changing-the-default-timeout). Note that it may require a quick reboot for the changes to take effect.
|
||||
|
||||
Additionally, to check how long a query is taking, you can check the Query Performance report which can give you more information on the query's performance: https://app.supabase.com/project/_/reports/query-performance. You can use the [query plan analyzer](https://www.postgresql.org/docs/current/sql-explain.html) on any expensive queries that you have identified: `explain analyze <query-statement-here>;`. For supabase-js/ postgREST queries you can use `.explain()`.
|
||||
|
||||
You can also make use of Postgres logs that will give you useful information like when the query was executed: https://app.supabase.com/project/_/logs/postgres-logs.
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title = "Edge Function 'wall clock time limit reached'"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/21293"
|
||||
date_created = "2024-02-15T11:42:58+00:00"
|
||||
topics = ["functions"]
|
||||
keywords = ["wall clock", "limit", "time", "shutdown"]
|
||||
|
||||
[[errors]]
|
||||
http_status_code = 546
|
||||
message = "Edge Function 'wall clock time limit reached'"
|
||||
---
|
||||
|
||||
**What Does "Wall Clock Time Limit Reached" Mean?**
|
||||
|
||||
The message "wall clock time limit reached" typically indicates that a process has reached the maximum time allowed for execution. This time is measured by a clock, similar to a system clock or a clock on the wall. It encompasses the entire duration a process takes to complete, including any periods of inactivity or waiting.
|
||||
|
||||
When this message appears in the context of your edge function, it means that the function has emitted a Shutdown event either after reaching the specified wall clock duration or when it hits a resource limit such as CPU time used or memory utilized.
|
||||
|
||||
**Current Limits Explained**
|
||||
|
||||
- Wall Clock Time Limit: Currently set at 400 seconds for the total duration your edge function can run.
|
||||
- CPU Execution Time: Limited to 200 milliseconds of active computing.
|
||||
|
||||
This means that if your edge function completes its task within these time constraints, there's no need to be concerned about the "wall clock time limit reached" error message.
|
||||
|
||||
Because the "wall clock time limit reached" warning can be expected in some cases. This message is hard-coded to be printed out when the worker has been terminated, even if it hasn't reached the time limit. However, if your function terminates with this warning and returns a 546 error response, then this indicates that your function is exceeding the allowed execution time, signaling a long-running task.
|
||||
|
||||
**Steps to Troubleshoot**
|
||||
If you're facing the "wall clock time limit reached" error with a 546 error code, here are actions to take:
|
||||
|
||||
- Review Your Function's Logic: Examine the operations within your edge function for any inefficiencies or prolonged processes. Consider optimizing code, minimizing unnecessary calculations, and implementing asynchronous operations where possible.
|
||||
|
||||
- Divide Complex Tasks: For functions handling complex or extensive tasks, try breaking them down into smaller, discrete functions. This approach can help manage workloads more effectively and stay within time limits.
|
||||
|
||||
- Monitor Execution Time: Use our logging or monitoring tools available to keep an eye on your function's performance. This can pinpoint where optimizations are necessary. To access logs visit: [Supabase Project Functions](https://app.supabase.com/project/_/functions) Select your function and click on Logs.
|
||||
|
||||
- Check Our Guides: For more tips, refer to our debugging guide here: [Debugging Edge Functions](https://supabase.com/docs/guides/functions/debugging#logs--debugging)
|
||||
|
||||
**Future Considerations**
|
||||
There are plans to make the wall clock time limit configurable per project in the future. However, currently, the only way to adjust this limit is by self-hosting [Edge Functions](https://github.com/supabase/edge-runtime/).
|
||||
|
||||
Stay updated on changes by regularly checking our changelog [here](https://github.com/orgs/supabase/discussions/categories/changelog).
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
title = "High latency with supabase client"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/22100"
|
||||
date_created = "2024-03-17T14:15:25+00:00"
|
||||
topics = ["database", "platform"]
|
||||
keywords = ["latency", "client", "performance"]
|
||||
---
|
||||
|
||||
## Describe the bug
|
||||
|
||||
Querying a table using the Supabase client is much slower than querying against the Postgres database directly.
|
||||
|
||||
## To Reproduce
|
||||
|
||||
1. Execute the below DDL statements.
|
||||
|
||||
```
|
||||
-- Create table
|
||||
CREATE TABLE your_table_name (
|
||||
id UUID PRIMARY KEY,
|
||||
column1 TEXT,
|
||||
column2 INT,
|
||||
column3 BOOLEAN
|
||||
);
|
||||
|
||||
-- Insert statements
|
||||
INSERT INTO your_table_name (id, column1, column2, column3) VALUES
|
||||
(uuid_generate_v4(), 'value1', 10, TRUE),
|
||||
(uuid_generate_v4(), 'value2', 20, FALSE),
|
||||
(uuid_generate_v4(), 'value3', 15, TRUE),
|
||||
(uuid_generate_v4(), 'value4', 8, FALSE),
|
||||
(uuid_generate_v4(), 'value5', 25, TRUE),
|
||||
(uuid_generate_v4(), 'value6', 12, FALSE),
|
||||
(uuid_generate_v4(), 'value7', 18, TRUE),
|
||||
(uuid_generate_v4(), 'value8', 30, FALSE),
|
||||
(uuid_generate_v4(), 'value9', 22, TRUE),
|
||||
(uuid_generate_v4(), 'value10', 5, FALSE),
|
||||
(uuid_generate_v4(), 'value11', 17, TRUE),
|
||||
(uuid_generate_v4(), 'value12', 9, FALSE),
|
||||
(uuid_generate_v4(), 'value13', 14, TRUE),
|
||||
(uuid_generate_v4(), 'value14', 28, FALSE),
|
||||
(uuid_generate_v4(), 'value15', 11, TRUE),
|
||||
(uuid_generate_v4(), 'value16', 7, FALSE),
|
||||
(uuid_generate_v4(), 'value17', 19, TRUE),
|
||||
(uuid_generate_v4(), 'value18', 26, FALSE),
|
||||
(uuid_generate_v4(), 'value19', 16, TRUE),
|
||||
(uuid_generate_v4(), 'value20', 21, FALSE);
|
||||
```
|
||||
|
||||
2. Run the following script (you may need to `pip install psycopg[binary]` in addition to supabase client.
|
||||
|
||||
```
|
||||
import time
|
||||
from supabase import Client, create_client
|
||||
|
||||
import psycopg
|
||||
|
||||
|
||||
def psycop_call(): #user_ids: list[str]):
|
||||
user="YOUR_SUPABASE_USER"
|
||||
password="YOUR_SUPABASE_PASSWORD"
|
||||
host="SUPABASE_HOST"
|
||||
port=5432
|
||||
database="postgres"
|
||||
|
||||
with psycopg.connect(f"host={host} port={port} dbname={database} user={user} password={password}") as conn:
|
||||
# Open a cursor to perform database operations
|
||||
results = []
|
||||
with conn.cursor() as cur:
|
||||
start = time.time()
|
||||
# Execute a command: this creates a new table
|
||||
cur.execute("SELECT * FROM public.your_table_name")
|
||||
cur.fetchall()
|
||||
for record in cur:
|
||||
results.append(record)
|
||||
stop = time.time()
|
||||
return (stop - start)
|
||||
|
||||
|
||||
def supabase_call():
|
||||
supabase: Client = create_client("SUPABASE_URL", "SUPBASE_SERVICE_ROLE_KEY")
|
||||
start = time.time()
|
||||
result = supabase.table("your_table_name").select("*").execute()
|
||||
stop = time.time()
|
||||
return (stop - start)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
ref = psycop_call()
|
||||
sup = supabase_call()
|
||||
print(f"postgres: {ref}, supabase: {sup}, ratio: {sup/ref}")
|
||||
```
|
||||
|
||||
3. You will see that the Supabase client takes longer to execute the same query, especially for smaller tables or queries returning just one row.
|
||||
|
||||
## Expected behavior
|
||||
|
||||
The overhead from PostgREST shouldn't be higher than a few milliseconds at max. 60-70 ms is way too high. This is particular deceiving because one can run the query on the SQL Editor page and it reports the same time as the direct postgres query, which is not what actually happens.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title = "How can I revoke execution of a PostgreSQL function?"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/17606"
|
||||
date_created = "2023-09-21T03:04:41+00:00"
|
||||
topics = ["database", "functions"]
|
||||
keywords = ["functions", "permissions"]
|
||||
|
||||
[[errors]]
|
||||
message = "ERROR: permission denied for function foo"
|
||||
---
|
||||
|
||||
All functions access is PUBLIC by default, this means that any role can execute it. To revoke execution, there are 2 steps required:
|
||||
|
||||
- Revoke function execution (`foo` in this case) from PUBLIC:
|
||||
|
||||
```sql
|
||||
revoke execute on function foo from public;
|
||||
```
|
||||
|
||||
- Revoke execution from a particular role (`anon` in this case):
|
||||
|
||||
```sql
|
||||
revoke execute on function foo from anon;
|
||||
```
|
||||
|
||||
Now `anon` should get an error when trying to execute the function:
|
||||
|
||||
```sql
|
||||
begin;
|
||||
set local role anon;
|
||||
select foo();
|
||||
ERROR: permission denied for function foo
|
||||
```
|
||||
@@ -2,7 +2,8 @@
|
||||
title = "Why is my camelCase name not working in Postgres functions or RLS policies?"
|
||||
github_url = "https://github.com/orgs/supabase/discussions/12893"
|
||||
date_created = "2023-03-08T16:26:51+00:00"
|
||||
topics = [ "database" ]
|
||||
topics = [ "database", "API" ]
|
||||
keywords = [ "camelCase", "Postgres", "functions", "RLS" ]
|
||||
database_id = "9dbcf760-7b1f-4cc4-8653-4e884fd02dad"
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user