whpg-diskquota

Use whpg-diskquota to limit the disk space that schemas, roles, and tablespaces use in a WarehousePG database. Starting with version 2.4, you can also limit the disk space used by a whole database or the entire cluster.

whpg-diskquota applies the same rule at each of the following scopes:

• Schema: limits all tables in a database that reside in a specific schema.
• Role: limits all tables in a database that a specific role owns, no matter which role's session writes to them.
• Tablespace: limits a schema's or role's usage on one tablespace in a database. A tablespace is the storage location on disk where WarehousePG keeps the data files for the tables and indexes assigned to it.
• Database: limits a whole database's total size.
• Cluster: limits the combined size of every monitored database.

For all scopes, a table's disk usage includes the table data, indexes, toast tables, and free space map, plus, for an append-optimized table, its visibility map and index, and its block directory table. whpg-diskquota sums this usage across every WarehousePG segment to get a scope's total.

How whpg-diskquota works

whpg-diskquota runs two kinds of background worker:

• The launcher. One runs per cluster, in the diskquota database. It keeps the list of monitored databases, starts and stops each database's worker, handles CREATE/DROP EXTENSION diskquota, and holds the cluster quota and running total.
• A worker. Each monitored database has its own worker, or shares a rotating pool of workers in dynamic mode (see diskquota.max_workers). Every diskquota.naptime seconds, it re-measures the tables that changed since its last pass, rolls the results up per schema, role, tablespace, and database, and publishes its database's total to the launcher.

The launcher only runs on the active coordinator node, and the standby coordinator's postmaster doesn't start it while in standby mode. When the coordinator goes down and an administrator runs gpactivatestandby, the standby coordinator becomes the coordinator, and the launcher starts automatically, using the monitored-database list in the diskquota database to recreate the workers. whpg-diskquota doesn't automatically resume monitoring a segment that's replaced by a mirror, though, so restart WarehousePG manually in that situation.

Each worker records every scope that's over quota in a shared structure called the rejectmap, and whpg-diskquota blocks writes in one of two ways:

• Soft limit (the default). The coordinator checks the rejectmap before a write runs and rejects it up front, so the query never starts.
• Hard limit (diskquota.hard_limit = on). Each database's worker also dispatches its rejectmap entries to the segments, which stop an over-quota query mid-execution.

Expect a short delay, up to one diskquota.naptime, before a new quota takes effect or a quota-exceeded scope clears. If you free space or raise a limit, writes resume on their own on the next cycle, without a restart or manual reset.

To get started with whpg-diskquota, see:

• Installing and upgrading whpg-diskquota
• Using whpg-diskquota
• Reference