S

silentworks•10/22/25, 9:06 PM

Not sure what this mean as the upgrade shouldn't affect your table schema nor your data at all. Can you provide an concrete example of what was working before that is not working now? since you tagged PostgREST in this post it would be good if you showed a code example of what is not working.

Y

ykandelOP•10/22/25, 9:16 PM

Issue: After applying a security migration that modified 90+ database functions (setting

search_path

search_path

search_path

search_path to prevent injection attacks), PostgREST started returning 404 errors for existing tables.

What was working → stopped working:

**Private Messages API:**```POST /rest/v1/private_messages?select=*→ 404 (Not Found)Error: relation "message_read_receipts" does not exist```
**RPC Function Calls:**```javascriptsupabase.rpc('check_user_can_send_message', { ... })→ Error: function check_user_can_send_message(uuid, text, text) does not exist```
**Course Enrollment:**```POST /rest/v1/course_enrollments→ Error: relation "courses" does not exist```

Database State:

All tables exist in
```
public
```
```
public
```
schema
All permissions granted to
```
anon
```
```
anon
```
and
```
authenticated
```
authenticated
```
authenticated
```
authenticated
roles
All functions exist with correct signatures
RLS policies are active and correct

tried reloading the scheme- didn't work... many times, 2 hours already.

V

vick•10/23/25, 2:56 AM

Once you set search path to empty, you need to provide the full path to reference any database object. Likely in your case you need to reference the table as

public.courses

public.courses

public.courses

public.courses within your function.

V

vick•10/23/25, 2:57 AM

As for why your function cannot be found, did you drop any grants when you redefined the functions?

Y

ykandelOP•10/23/25, 5:42 AM

I diagonsed this-
Symptoms:

NEW objects (created after restart) work:
- Table 'postgrest_test' - INSERT works
- Function 'test_postgrest_function' - RPC works
OLD objects (existing before restart) fail:
- Table 'waitlist' - 404 "relation does not exist"
- All other existing tables fail similarly
Database verification:
All tables exist in PostgreSQL (verified via SQL) + UI + MCP Access ( that skips PostaREST where I think is the problem)
All permissions are correct (authenticated/anon have access)
RLS policies are intact

Actions taken:

NOTIFY pgrst, 'reload schema' - multiple times
Disk upgrade Nano→Micro (triggered full restart)
Issue persists

Y

ykandelOP•10/23/25, 8:56 AM

I think it's corrupted. after more testing it seems that it's just died... no relations

Y

ykandelOP•10/23/25, 9:03 AM

after analysing the logs from PostgREST i see-

I Upgrade from
PostgreSQL 15.8 to 17.6 with the ->
Schema cache: 75 Relations, 79 Functions

### **During Disk Upgrade (timestamp 1761159159-1761159604):**

### **During Disk Upgrade (timestamp 1761159159-1761159604):**

### **During Disk Upgrade (timestamp 1761159159-1761159604):**

### **During Disk Upgrade (timestamp 1761159159-1761159604):**

FATAL: terminating connection due to administrator command
SSL connection has been closed unexpectedly
Connection refused (repeated many times)

### **After Restart (timestamp 1761159049):**

### **After Restart (timestamp 1761159049):**

### **After Restart (timestamp 1761159049):**

### **After Restart (timestamp 1761159049):**

PostgreSQL 17.6 ← MAJOR VERSION UPGRADE!
Schema cache: 0 Relations ← COMPLETELY EMPTY!

### **Gradual Recovery:**

### **Gradual Recovery:**

### **Gradual Recovery:**

### **Gradual Recovery:**

timestamp 1761159582: 75 Relations ← Missing tables!
timestamp 1761180775: 77 Relations ← Your NOTIFY commands
timestamp 1761197475: 78 Relations ← After creating postgrest_test
timestamp 1761208375: 78 Relations ← Current state

## :rotating_light: What Actually Happened:

**You didn't just change disk size - Supabase also upgraded your PostgreSQL from 15.8 → 17.6!**

During this major version upgrade:
1. Database was migrated to new version
2. PostgREST restarted
3. PostgREST loaded schema cache **during the migration**
4. Cache captured only **0 Relations** initially
5. Then **75 Relations** (incomplete)
6. Now stuck at **78 Relations** (still missing tables)


During disk upgrade (Nano→Micro), PostgreSQL was upgraded to 17.6.
PostgREST loaded schema cache during migration and captured incomplete state.

Evidence from logs:
- Before: PostgreSQL 15.8, 75 Relations
- During upgrade: Multiple connection failures
- After: PostgreSQL 17.6, started with 0 Relations
- Current: Stuck at 78 Relations (should be 80+)
- New tables ARE visible, old tables return 404

Need: Full PostgREST service restart to rebuild schema cache

## :rotating_light: What Actually Happened:

**You didn't just change disk size - Supabase also upgraded your PostgreSQL from 15.8 → 17.6!**

During this major version upgrade:
1. Database was migrated to new version
2. PostgREST restarted
3. PostgREST loaded schema cache **during the migration**
4. Cache captured only **0 Relations** initially
5. Then **75 Relations** (incomplete)
6. Now stuck at **78 Relations** (still missing tables)


During disk upgrade (Nano→Micro), PostgreSQL was upgraded to 17.6.
PostgREST loaded schema cache during migration and captured incomplete state.

Evidence from logs:
- Before: PostgreSQL 15.8, 75 Relations
- During upgrade: Multiple connection failures
- After: PostgreSQL 17.6, started with 0 Relations
- Current: Stuck at 78 Relations (should be 80+)
- New tables ARE visible, old tables return 404

Need: Full PostgREST service restart to rebuild schema cache

## :rotating_light: What Actually Happened:

**You didn't just change disk size - Supabase also upgraded your PostgreSQL from 15.8 → 17.6!**

During this major version upgrade:
1. Database was migrated to new version
2. PostgREST restarted
3. PostgREST loaded schema cache **during the migration**
4. Cache captured only **0 Relations** initially
5. Then **75 Relations** (incomplete)
6. Now stuck at **78 Relations** (still missing tables)


During disk upgrade (Nano→Micro), PostgreSQL was upgraded to 17.6.
PostgREST loaded schema cache during migration and captured incomplete state.

Evidence from logs:
- Before: PostgreSQL 15.8, 75 Relations
- During upgrade: Multiple connection failures
- After: PostgreSQL 17.6, started with 0 Relations
- Current: Stuck at 78 Relations (should be 80+)
- New tables ARE visible, old tables return 404

Need: Full PostgREST service restart to rebuild schema cache

## :rotating_light: What Actually Happened:

**You didn't just change disk size - Supabase also upgraded your PostgreSQL from 15.8 → 17.6!**

During this major version upgrade:
1. Database was migrated to new version
2. PostgREST restarted
3. PostgREST loaded schema cache **during the migration**
4. Cache captured only **0 Relations** initially
5. Then **75 Relations** (incomplete)
6. Now stuck at **78 Relations** (still missing tables)


During disk upgrade (Nano→Micro), PostgreSQL was upgraded to 17.6.
PostgREST loaded schema cache during migration and captured incomplete state.

Evidence from logs:
- Before: PostgreSQL 15.8, 75 Relations
- During upgrade: Multiple connection failures
- After: PostgreSQL 17.6, started with 0 Relations
- Current: Stuck at 78 Relations (should be 80+)
- New tables ARE visible, old tables return 404

Need: Full PostgREST service restart to rebuild schema cache

This explains why the NOTIFY commands didn't work - the cache was corrupted at initialization during a major database upgrade!

Your support ticket just became much higher priority

PostgreSQL upgrades with corrupted API caches are serious incidents!
```
"Claude observation...."

Y

ykandelOP•10/23/25, 10:49 AM

I'm looking at the js->

POST .../qa_question_votes  // Trying to insert into THIS table
message: 'relation "qa_questions" does not exist'  // But error about THIS table

POST .../qa_question_votes  // Trying to insert into THIS table
message: 'relation "qa_questions" does not exist'  // But error about THIS table

POST .../qa_question_votes  // Trying to insert into THIS table
message: 'relation "qa_questions" does not exist'  // But error about THIS table

POST .../qa_question_votes  // Trying to insert into THIS table
message: 'relation "qa_questions" does not exist'  // But error about THIS table

You're inserting into

qa_question_votes

qa_question_votes

qa_question_votes

qa_question_votes, but the error is about

qa_questions

qa_questions

qa_questions

qa_questions!

This means PostgREST has a corrupted view of table relationships! It can see some tables but not the foreign key references between them.

Let me verify the foreign keys:

Your error is NOT about the table you're inserting into - it's about the foreign key reference!

Inserting into: qa_question_votes
Foreign key points to: qa_questions (question_id → qa_questions.id)
Error: "qa_questions" does not exist

Inserting into: qa_question_votes
Foreign key points to: qa_questions (question_id → qa_questions.id)
Error: "qa_questions" does not exist

Inserting into: qa_question_votes
Foreign key points to: qa_questions (question_id → qa_questions.id)
Error: "qa_questions" does not exist

Inserting into: qa_question_votes
Foreign key points to: qa_questions (question_id → qa_questions.id)
Error: "qa_questions" does not exist

PostgREST's RELATIONSHIPS cache is corrupted!

The logs show:

78 Relations loaded
114 Relationships loaded (BUT BROKEN!)

PostgREST can "see" the tables exist, but its internal relationship graph is corrupted. When you try to insert into a table with foreign keys, PostgREST tries to validate the referenced table exists and fails because its relationship cache is pointing to phantom tables!

This Explains Everything:

READ operations: Work fine (no FK validation needed)
WRITE operations: Fail (PostgREST validates FKs first)
New table (
postgrest_test
postgrest_test
postgrest_test
postgrest_test): Works (no foreign keys!)
Old tables with FKs: Fail (corrupted relationship cache)

##

The Solution:

Same as before - PostgREST service restart

but now you know the exact issue:
```
CRITICAL: PostgREST relationship cache corrupted after PG 15.8→17.6 upgrade

elations cache: 78 tables (correct)
Relationships cache: 114 relationships (CORRUPTED)
```

Does someone knows? I did PostgREST restart many times without any change??

Y

ykandelOP•10/23/25, 10:50 AM

I need a full restart maybe- with->

Kill PostgREST process

ykandel · 2025-10-22T20:46:53.051Z

I upgraded my postgres to 17 and after the upgrade all the relations aren’t working anymore… someone knows what can I do in order to return them and not manually adding them again?

killall -SIGUSR1 postgrest

OR

systemctl restart postgrest

G

garyaustin•10/23/25, 1:12 PM

Check your exposed schemas and default search path in API settings.
Check your Postgres log if you have not.

Y

ykandelOP•10/23/25, 1:34 PM

already did...

G

garyaustin•10/23/25, 1:35 PM

Actually meant your PostgREST logs.

G

garyaustin•10/23/25, 1:38 PM

A full restart is done by doing a project restart from your general settings.

Y

ykandelOP•10/23/25, 2:07 PM

I restarted aswell and didn't solve it...
for example this error->

fetch.js:30
POST https://snkbzqzypbyjawrvvvtr.supabase.co/rest/v1/rpc/send_realtime_message 404 (Not Found)

realtime.ts:140 Database function error:
{code: '42883', details: null, hint: 'No function matches the given name and argument types. You might need to add explicit type casts.', message: 'function check_user_can_send_message(uuid, text, text) does not exist'}
index.tsx:915

[REALTIME] Error sending message: Error: function check_user_can_send_message(uuid, text, text) does not exist
at _callee7$ (index.tsx:912:15)

while I have in my db the function send_realtime_message relation ->
check_user_can_send_message
p_user_id uuid, p_channel_id text, p_community_id text

boolean

Definer

and more...

Y

ykandelOP•10/23/25, 2:08 PM

when I do it from the MCP to Postgres it's working

G

garyaustin•10/23/25, 2:08 PM

If your PostgREST logs don't show schema cache errors then you need to reach out to support.

Y

ykandelOP•10/23/25, 2:08 PM

the REST logs showing like it's loaded-

Y

ykandelOP•10/23/25, 2:09 PM

Schema cache loaded in 2.8 milliseconds
Schema cache loaded 78 Relations, 114 Relationships, 84 Functions, 0 Domain Representations, 4 Media Type Handlers, 1194 Timezones
Schema cache queried in 12.0 milliseconds
Config reloaded
Successfully connected to PostgreSQL 17.6 on aarch64-unknown-linux-gnu, compiled by gcc (GCC) 13.2.0, 64-bit
Connection Pool initialized with a maximum size of 20 connections
Received a schema cache reload message on the "pgrst" channel

G

garyaustin•10/23/25, 2:10 PM

I've seen your symptoms when the REST logs show a schema cache error. And several cases where the API settings had a schema in them that no longer existed in the DB. If you have a schema in exposed schema that no longer exists the schema cache.

Your error message seems to say that is not the issue...

Y

ykandelOP•10/23/25, 2:11 PM

I understand.... Still trying write into the db doesn't work using postgREST

Y

ykandelOP•10/23/25, 2:11 PM

when I created a new table I managed to write into it but for old ones no.

Y

ykandelOP•10/23/25, 2:12 PM

From the AI observation it seems like it is this- PostgREST's RELATIONSHIPS cache is corrupted

G

garyaustin•10/23/25, 2:15 PM

But that loads new each time you restart. And a reason for corruption is like I said with the API schemas (especially an extra one that does not exist in 17 versus 15) BUT you would have an error in the PostgREST logs about that.

Otherwise not having a needed schema in the exposed schema settings or search path could cause your symptom too.

Y

ykandelOP•10/23/25, 2:16 PM

I also see that my edge functions that tried to write into one of the tables got the same error-
"

Insert failed: {\n code: "42P01",\n details: null,\n hint: null,\n message: 'relation "waitlist" does not exist'\n}\n"

where the debug-
"Error processing PayPal webhook: Error: Failed to create placeholder record: relation "waitlist" does not exist\n at handleBillingSubscriptionActivated (file:///var/tmp/sb-compile-edge-runtime/functions/paypal-webhook-handler/index.ts:278:15)\n at eventLoopTick (ext:core/01_core.js:175:7)\n at async Server.<anonymous> (file:///var/tmp/sb-compile-edge-runtime/functions/paypal-webhook-handler/index.ts:898:9)\n at async Server.#respond (https://deno.land/std@0.208.0/http/server.ts:224:18)\n"

Deno

Third Party | Deno

G

garyaustin•10/23/25, 2:16 PM

They would as they use the same REST API.

Y

ykandelOP•10/23/25, 2:17 PM

yes make sense...

Y

ykandelOP•10/23/25, 2:17 PM

so it's only supabase support

Y

ykandelOP•10/23/25, 2:17 PM

to help me with that

Y

ykandelOP•10/23/25, 2:17 PM

?

G

garyaustin•10/23/25, 2:19 PM

Well you have had the 3 of the best users here for this type of issue participate in this thread.
And either you are missing some error/info we need, or we all are missing some question to ask you. No one here can see your instance and this has not happened on any 15 to 17 conversion (except the case I mentioned of schema going away) that I know of. That was also Silentworks comment.

Y

ykandelOP•10/23/25, 2:21 PM

hmm, okay what do you recommend me doing further? since creating new tables and writing into them works, should I just create temp tables with all the data and then delete all the original ones and then create the original tables with the name with all the data from the temp? will that resolve possibly?

Y

ykandelOP•10/23/25, 2:21 PM

or should I just wait for the support

G

garyaustin•10/23/25, 2:23 PM

If Pro I would wait for support, if Free I would start working on my own solution.

Y

ykandelOP•10/23/25, 2:24 PM

will switching into backup of yesterday's state- before the update will resolve it?

G

garyaustin•10/23/25, 2:25 PM

As we don't know what the issue is hard to say.

Y

ykandelOP•10/23/25, 2:25 PM

hmm hard...

Y

ykandelOP•10/23/25, 2:26 PM

Well, thank you though

G

garyaustin•10/23/25, 2:29 PM

Can you show your API settings for exposed schema and search path?

Y

ykandelOP•10/23/25, 2:37 PM

Exposed schemas

graphql_public
public
Select schemas for Data API...
The schemas to expose in your API. Tables, views and stored procedures in these schemas will get API endpoints.
Extra search path

public
extensions
Select schemas to add to search path...
Extra schemas to add to the search path of every request.

G

garyaustin•10/23/25, 2:39 PM

Don't see any issue with that as long as all your tables/functions are in public schema.

G

garyaustin•10/23/25, 2:42 PM

And I assume this is on.

G

garyaustin•10/23/25, 3:15 PM

Have you check RLS settings?
Try using an impersonated user in the SQL editor and see if your Selects work there.

G

garyaustin•10/23/25, 3:17 PM

I noticed you ran some sort of migration...
Was that after you upgraded to the new DB?
Could that have modified your RLS?

Y

ykandelOP•10/23/25, 3:45 PM

I don't think its an RLS issue.
I have the following:

HTTP Status: 404 (Not Found), not 403 (Forbidden)
Error Code:
```
42P01
```
42P01
```
42P01
```
42P01
("undefined_table"), not permission denied

SQL Editor Test:

Works fine as authenticated user:

SET ROLE authenticated;
SELECT COUNT(*) FROM waitlist; -- Returns 66 rows
RESET ROLE;

SET ROLE authenticated;
SELECT COUNT(*) FROM waitlist; -- Returns 66 rows
RESET ROLE;

SET ROLE authenticated;
SELECT COUNT(*) FROM waitlist; -- Returns 66 rows
RESET ROLE;

SET ROLE authenticated;
SELECT COUNT(*) FROM waitlist; -- Returns 66 rows
RESET ROLE;

RLS Status: Enabled and functioning on all affected tables
Migration Timeline: No migrations run AFTER the PostgreSQL 15.8→17.6 upgrade

Key Evidence:

Direct PostgreSQL queries: Work
PostgREST API calls: Return 404 "relation does not exist"
NEW tables created AFTER upgrade: Work via PostgREST
OLD tables from BEFORE upgrade: 404 via PostgREST

Diagnosis: PostgREST's schema cache corrupted during the PostgreSQL version upgrade. The cache shows "78 Relations loaded" but returns 404 when accessing them. RLS policies never execute because PostgREST can't find the tables in its cache to begin with.

I didn't run the migration after, only before and it worked..

Y

ykandelOP•10/23/25, 4:44 PM

OKAYYYY I FOUND THE SOLUTION->

90+ database functions had a security vulnerability called "search path injection"
I did this fix- -- Changed ALL functions from:
CREATE FUNCTION my_function()
...
SET search_path = public;

-- To this:
CREATE FUNCTION my_function()
...
SET search_path = '';

But the function code still referenced tables WITHOUT schema names:

resulted- Result:
Security vulnerability fixed
BUT all functions with unqualified table names BROKE IMMEDIATELY
You just didn't notice because you didn't test INSERTs thoroughly

after understanding the search path was empty I reverted with- -- Reverted ALL 100+ functions from:
SET search_path = ''

-- Back to:
SET search_path = public

which Solved it.

Y

ykandelOP•10/23/25, 4:44 PM

Thank you very much for you time and support here, and feedback and trying to help.!

G

garyaustin•10/23/25, 4:49 PM

Looks like Vick had that part... Postgres db update

Y

ykandelOP•10/23/25, 4:57 PM

indeed...

Y

ykandelOP•10/23/25, 4:57 PM

Thank you!

Postgres db update

This Explains Everything:

Kill PostgREST process

OR

Similar Threads

Similar Threads

Similar Threads

This Explains Everything:

Kill PostgREST process

OR