On Thu, Sep 21, 2017 at 1:09 PM, Meel Velliste <meel@xxxxxxxxxxxx> wrote: > In this situation, neither us, nor our customer has the power to install the > required monitoring of pg_xlog. The database hosting provider would have to > do it. In most cases (e.g. Amazon RDS) the hosting provider does provide a > way of monitoring overall disk usage, which may be good enough. But I am > thinking it would make sense for postgres to have default, built-in > monitoring that drops all the slots when pg_xlog gets too full (based on > some configurable limit). Otherwise everybody has to build their own > monitoring and I imagine 99% of them would want the same behavior. Nobody > wants their database to fail just because some client was not reading the > slot. (Please avoid top-posting, this breaks the logic of the thread and this is contrary to the practices of the Postgres mailing lists) Note that on-disk lookup is not strictly necessary. If you know max_wal_size, pg_current_wal_lsn (or pg_last_wal_receive_lsn if working on a standby) and the restart_lsn of the slots that's enough. If you don't have privileges sufficient to see that, well I guess that you will need to review the access permissions to your instance. Postgres 9.6 offers better access control to system functions, so you could be granted access to just those resources to be fine using a SQL session. -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
