whpg-diskquota reference

whpg-diskquota exposes server configuration parameters, user-defined functions (UDFs), and views, all in the diskquota schema. Set configuration parameters with gpconfig, the same way you'd set any other WarehousePG server configuration parameter. Prepend the schema name (diskquota.) to a function or view name, unless the diskquota schema is already on your search_path.

Configuration parameters

diskquota.hard_limit

Activates or deactivates hard limit enforcement of disk usage.

It defaults to off, and a change takes effect on reload.

With hard limit enforcement on, whpg-diskquota also checks quotas during query execution, and terminates a running query once the worker's next cycle finds that it pushed a scope over its limit. With hard limit enforcement off, the default, whpg-diskquota only checks quotas before a query starts, so a query already running can push a scope over its limit and still complete.

A write only gets caught by hard limit enforcement if it's still running after the worker's next cycle. A write that finishes within one diskquota.naptime completes even with hard limit enforcement on, since the worker hasn't yet had a chance to measure the new usage and dispatch a rejectmap entry to the segments.

See Activating or deactivating hard limit enforcement to turn it on or off.

diskquota.max_active_tables

Sets the maximum number of relations, including tables and indexes, that whpg-diskquota can monitor for changes at the same time.

It defaults to 307200 (300 * 1024), and a change takes effect on restart.

whpg-diskquota uses shared memory to hold the rejectmap and the list of active tables. The rejectmap can hold up to one million database objects that are over quota. If it fills up, data can be loaded into some schemas, roles, databases, or the cluster after they've already reached their quota.

Active table shared memory holds up to diskquota.max_active_tables entries, 307200 by default. Active tables are tables that might have changed size since whpg-diskquota last recalculated table sizes. whpg-diskquota's hook functions run when the storage manager on a WarehousePG segment creates, extends, or truncates a table file, and record the file's identity in shared memory so its size gets recalculated on the next refresh. The default value is sufficient for most WarehousePG installations.

See Raising the maximum number of active tables to change it.

diskquota.max_monitored_databases

Sets the maximum number of databases that whpg-diskquota can monitor at the same time. You can raise it to a maximum of 1024.

It defaults to 50, and a change takes effect on restart.

diskquota.max_quota_probes

Sets the maximum number of schema, role, and tablespace quota entries that whpg-diskquota can track across the cluster.

It defaults to 1048576 (1024 * 1024), and a change takes effect on restart.

diskquota.max_table_segments

Sets the maximum number of table segments (shards) in the cluster that whpg-diskquota can track, which in turn gates the maximum number of tables it can monitor.

It defaults to 10485760 (10 * 1024 * 1024), and a change takes effect on restart.

A WarehousePG table, including a partitioned table's child tables, is distributed to every segment as a shard, and whpg-diskquota counts each shard as a table segment. The runtime value of diskquota.max_table_segments equals <max_number_tables> * ceil((<number_segments> + 1) / 100) * 100. When you expand your WarehousePG cluster, each table consumes more table segments, which can reduce the maximum number of tables that whpg-diskquota supports, and can trigger this warning:

[diskquota] the number of tables exceeds the limit, please increase the GUC value for diskquota.max_table_segments.

See Raising the maximum number of table segments to change it.

diskquota.max_workers

Sets the maximum number of whpg-diskquota worker processes, not including the launcher, that can run at the same time. The maximum value you can set is 20.

It defaults to 10, and a change takes effect on restart.

This limit determines how the launcher assigns workers to monitored databases. While the number of monitored databases is at or under diskquota.max_workers, whpg-diskquota runs in static mode, and each monitored database keeps a dedicated worker. In static mode, whpg-diskquota can fail to monitor some databases if fewer background worker processes are available than diskquota.max_workers allows. Once the number of monitored databases exceeds diskquota.max_workers, whpg-diskquota switches to dynamic mode, and the launcher rotates the available workers across all the monitored databases instead. In dynamic mode, whpg-diskquota works correctly as long as at least one background worker process is available.

See Increasing the number of worker processes to change it.

diskquota.naptime

Controls how often, in seconds, a worker recalculates table sizes.

It defaults to 2, and a change takes effect on reload.

A smaller value reduces the delay before whpg-diskquota detects a change in disk usage, at the cost of more frequent size checks. There's always some delay between a quota being reached and the scope actually being added to the rejectmap, since worker cycles run with a pause between them, and since operations that remove data, such as DROP, TRUNCATE, or VACUUM FULL, also only take effect on the next cycle.

See Setting the delay between disk usage updates to change it.

diskquota.worker_timeout

Sets the number of seconds wait_for_worker_new_epoch() waits for the worker before it logs a NOTICE that the worker may be unresponsive. The function keeps waiting after the notice.

It defaults to 60, and a change takes effect on reload.

Functions

Call these functions to set quotas, control enforcement, and monitor whpg-diskquota. See Setting quotas and Controlling quota enforcement for examples.

Views

Query these views to check the quotas and disk usage whpg-diskquota tracks. See Displaying disk quotas and disk usage for examples.