On Wed, Nov 16, 2022 at 7:59 AM Maxim Orlov <orlovmg@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