> 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.
Yes, you are right. Actually, this is one of possible ways to deal with described situation I mentioned above. And if I would deal with such a task, I would make it via log monitoring. The question was: "could we be more general here?". Probably, not. > 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. > OK, I got it. Thanks for your thoughts! -- Best regards, Maxim Orlov.
