On Thu, 17 Nov 2022 at 14:56, Robert Haas <[email protected]> wrote: > > Having a switch for one particular kind of error (out of many that > could possibly occur) that triggers one particular coping strategy > (out of many that could possibly be used) seems far too specific a > thing to add as a core feature. And even if we had something much more > general, I'm not sure why that should go into the database rather than > being implemented outside it. After all, nothing at all prevents the > user from scanning the database logs for "out of space" errors and > shutting down the database if any are found. While you're at it, you > could make your monitoring script also check the free space on the > relevant partition using statfs() and page somebody if the utilization > goes above 95% or whatever threshold you like, which would probably > avoid service outages much more effectively than $SUBJECT.
I have often thought we report a lot of errors to the user as transaction errors that database admins are often going to feel they would rather treat as system-wide errors. Often the error the user sees seems like a very low level error with no context that they can't do anythign about. This seems to be an example of that. I don't really have a good solution for it but I do think most users would rather deal with these errors at a higher level than individual queries from individual clients. Out of disk space, hardware errors, out of memory, etc they would rather handle in one centralized place as a global condition. You can work around that with middleware/libraries/monitoring but it's kind of working around the database giving you the information at the wrong time and place for your needs.
