This section describes the internals of a9s PostgreSQL.
The a9s PostgreSQL service instance has a special user called
cfuser. Every user (e.g., created
cf bind-service or
cf create-service-key) inherits its privileges and capabilities from
cfuser, which means that every user has access to two roles: its own and the
cfuser. The default role used when connecting is the
All objects in the default database must belong to the
cfuser. Otherwise, other users are not
able to access them. When changing the user role using
SET ROLE or
ALTER ROLE, one must be careful about
the ownership and accessibility of tables, sequences, views, and other objects. When deleting a
credential, all objects belonging to the user are being deleted and the ownership is transferred to
It is possible to configure the privileges for
cfuser and the users who inherits from
via custom parameters during instance creation (
cf create-service and
and the user that inherits from
cfuser during credentials creation (
cf bind-service or
cf create-service-key), check the documentation to know how.
Replication Slots Cleanup
A PostgreSQL user configured with the
REPLICATION role privilege can create
to replicate directly from a node.
When an application is connected and streaming using a replication slot, this slot is marked as active, and every WAL file that is replicated by all replication slots are recycled. When a replication slot is marked as inactive, the WAL files are kept and not recycled until that all slots streams the changes from that file. This means that when a slot is inactive, WAL files can consume all the available storage in the persistent disk and break the cluster.
a9s PostgreSQL ships the Replication Slot Reaper routine, which periodically drops inactive replication slots if they are inactive for too long or if it is inactive and the persistent disk usage has hit a threshold. To know these configuration values, consult the platform operator.