Re: [PoC] configurable out of disk space elog level

> 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.