fix: Do not clear the schema cache during retries#4869
Conversation
mkleczek
force-pushed
the
push-olktzqvzkonu
branch
from
c468e80 to
36be579
Compare
|
Clarifying the motivation on #4873 |
mkleczek
force-pushed
the
push-olktzqvzkonu
branch
2 times, most recently
from
5201ea9 to
82cf2e7
Compare
|
Follow up question on #4873 (comment), not sure if it's correct to do the fix like this. |
mkleczek
force-pushed
the
push-olktzqvzkonu
branch
3 times, most recently
from
02f8fbc to
4d6a87d
Compare
@steve-chavez - So what's the conclusion after #4873 (comment), #4873 (comment) and all discussions in #4873 ? Are we going to proceed with this PR? |
|
@mkleczek We need to clarify what are we going to do with the request "waiting" (not sure how to call this) mentioned on #4873 (comment) because there's also a scenario here where we void the schema cache and we force clients to wait while the schema cache is reloaded again. If that "waiting" is useless, let's settle it on #4873 (comment). |
mkleczek
force-pushed
the
push-olktzqvzkonu
branch
8 times, most recently
from
f92122f to
3b60b73
Compare
|
Now that we clarified the "waiting" was ineffective on #4937, let's proceed with reviewing this. |
mkleczek
force-pushed
the
push-olktzqvzkonu
branch
3 times, most recently
from
e685d2f to
5f3f373
Compare
mkleczek
force-pushed
the
push-olktzqvzkonu
branch
2 times, most recently
from
8a684e0 to
0bbfaf9
Compare
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
force-pushed
the
push-olktzqvzkonu
branch
from
0bbfaf9 to
31998c5
Compare
| - Shutdown should wait for in flight requests by @mkleczek in #4702 | ||
| - Remove automatic transaction retries on `40001 (serialization_failure)` errors to prevent replication lag by @laurenceisla in #3673 | ||
| - Fix unexpected results when embedding and filtering the same table more than once by @laurenceisla in #4075 | ||
| - PostgREST no longer returns voids schema cache during loading retries by @mkleczek in #4873 #4869 |
There was a problem hiding this comment.
This needs to be more user facing, currently it mentions an implementation detail. Maybe:
| - PostgREST no longer returns voids schema cache during loading retries by @mkleczek in #4873 #4869 | |
| - If the schema cache fails to reload, PostgREST will no longer stop serving requests and will continue doing so in a "best effort" basis by @mkleczek in #4873 #4869 |
4 participants
DISCLAIMER:
This commit was authored entirely by a human without the assistance of LLMs.
retryingSchemaCacheLoadshould 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