On Wed, Nov 16, 2022 at 7:59 AM Maxim Orlov <orlo...@gmail.com> wrote: > The customer, mentioned above, in this particular case, would be glad to be > able to have a mechanism to stop the cluster. > Again, in this concrete case. > > My proposal is to add a tablespace option in order to be able to configure > which behaviour is appropriate for a > particular user. I've decided to call this option “on_no_space” for now. If > anyone has a better naming for this feature, > please, report.
I don't think this is a good feature to add to PostgreSQL. First, it's unclear why stopping the cluster is a desirable behavior. It doesn't stop the user transactions from failing; it just makes them fail in some other way. Now it is of course perfectly legitimate for a particular user to want that particular behavior anyway, but there are a bunch of other things that a user could equally legitimately want to do, like page the DBA or trigger a failover or kill off sessions that are using large temporary relations or whatever. And, equally, there are many other operating system errors to which a user could want the database system to respond in similar ways. For example, someone might want any given one of those treatments when an I/O error occurs writing to the data directory, or a read-only filesystem error, or a permission denied error. 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 just can't see much real benefit in putting this logic inside the database. -- Robert Haas EDB: http://www.enterprisedb.com