Skip to content

fix: Do not clear the schema cache during retries#4869

Open
mkleczek wants to merge 1 commit intoPostgREST:mainfrom
mkleczek:push-olktzqvzkonu
Open

fix: Do not clear the schema cache during retries#4869
mkleczek wants to merge 1 commit intoPostgREST:mainfrom
mkleczek:push-olktzqvzkonu

Conversation

@mkleczek
Copy link
Copy Markdown
Collaborator

@mkleczek mkleczek commented May 4, 2026

DISCLAIMER:
This commit was authored entirely by a human without the assistance of LLMs.

retryingSchemaCacheLoad should not clear existing schema cache upon failure - there is no reason to do that.
If there is a communication issue with the database server or db is down, clients are going to get 502 anyway. If it was a glitch when loading the schema cache - the clients are going to use old (stale) schema cache for some time until next retry re-loads it successfully.

Fixes #4873

@mkleczek mkleczek requested a review from steve-chavez May 4, 2026 07:49
@mkleczek mkleczek force-pushed the push-olktzqvzkonu branch from c468e80 to 36be579 Compare May 4, 2026 17:35
@steve-chavez
Copy link
Copy Markdown
Member

Clarifying the motivation on #4873

Comment thread CHANGELOG.md Outdated
- Restore Listener query shape so it can be found in pg_stat_activity by @mkleczek in #4857 #4859
- The LISTEN channel now automatically recovers when it stops working due to a PostgreSQL bug @laurenceisla in #3147
- Fix misleading "Functions" name on schema cache summary in startup logs by @taimoorzaeem in #4821
- PostgREST no longer returns 503 error during schema cache loading retries by @mkleczek in #4869
Copy link
Copy Markdown
Member

@steve-chavez steve-chavez May 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true? IIRC if the DB is down we will return 503 while schema cache retrying.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's too strong. Fixed.

@mkleczek mkleczek force-pushed the push-olktzqvzkonu branch from 36be579 to 5201ea9 Compare May 4, 2026 18:08
retryingSchemaCacheLoad should not clear existing schema cache upon failure - there is no reason to do that. If there is a communication issue with the database server or db is down, clients are going to get 502 anyway. If it was a glitch when loading the schema cache - the clients are going to use old (stale) schema cache for some time until next retry re-loads it successfully.
@mkleczek mkleczek force-pushed the push-olktzqvzkonu branch from 5201ea9 to 82cf2e7 Compare May 4, 2026 18:08
@steve-chavez
Copy link
Copy Markdown
Member

Follow up question on #4873 (comment), not sure if it's correct to do the fix like this.

Comment thread test/io/test_io.py
**defaultenv,
"PGUSER": role,
"PGRST_DB_ANON_ROLE": role,
"PGRST_DB_ANON_ROLE": "postgrest_test_anonymous",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like an unrelated fix for that test, which we should merge independently, so that we don't forget to do that even if we end up not doing the PR (as-is).

Is my interpretation correct?

postgrest_test_serializable, postgrest_test_repeatable_read,
postgrest_test_w_superuser_settings TO :"PGUSER";

GRANT postgrest_test_anonymous TO timeout_authenticator;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not needed with the change to test_io.py, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

A statement timeout can void the schema cache

3 participants