Yandex.Cloud
  • Services
  • Why Yandex.Cloud
  • Pricing
  • Documentation
  • Contact us
Get started
Yandex Managed Service for PostgreSQL
  • Getting started
  • Step-by-step instructions
    • All instructions
    • Information about existing clusters
    • Creating clusters
    • Connecting to databases
    • Stop and start the cluster
    • SQL queries in the management console
    • Changing cluster and database settings
    • Connecting to DataLens
    • Managing PostgreSQL hosts
    • Database management
    • How to manage PostgreSQL extensions
    • Managing database users
    • Granting permissions and roles
    • Managing backups
    • Deleting clusters
    • Database migration to the Cloud
    • Creating a logical replica of Amazon RDS for PostgreSQL in Managed Service for PostgreSQL
  • Solutions
    • Creating a PostgreSQL cluster for 1C
  • Concepts
    • Relationship between service resources
    • Host classes
    • Network in Yandex Managed Service for PostgreSQL
    • Quotas and limits
    • Storage types
    • Backups
    • Assigning roles
    • Replication
    • Supported clients
  • Access management
  • Pricing policy
    • Current pricing policy
    • Archive
      • Before January 1, 2019
      • From January 1 to March 1, 2019
      • From March 1, 2019 to February 1, 2020
  • API reference
    • Authentication in the API
    • gRPC
      • Overview
      • BackupService
      • ClusterService
      • DatabaseService
      • ResourcePresetService
      • UserService
      • OperationService
    • REST
      • Overview
      • Backup
        • Overview
        • get
        • list
      • Cluster
        • Overview
        • addHosts
        • backup
        • create
        • delete
        • deleteHosts
        • get
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • move
        • rescheduleMaintenance
        • restore
        • start
        • startFailover
        • stop
        • streamLogs
        • update
        • updateHosts
      • Database
        • Overview
        • create
        • delete
        • get
        • list
        • update
      • ResourcePreset
        • Overview
        • get
        • list
      • User
        • Overview
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Overview
        • get
  • Questions and answers
    • General questions
    • Questions about PostgreSQL
    • All questions on the same page
  1. API reference
  2. REST
  3. User
  4. list

Method list

  • HTTP request
  • Path parameters
  • Query parameters
  • Response

Retrieves the list of PostgreSQL User resources in the specified cluster.

HTTP request

GET https://mdb.api.cloud.yandex.net/managed-postgresql/v1/clusters/{clusterId}/users

Path parameters

Parameter Description
clusterId Required. ID of the cluster to list PostgreSQL users in. To get the cluster ID, use a list request. The maximum string length in characters is 50.

Query parameters

Parameter Description
pageSize The maximum number of results per page to return. If the number of available results is larger than page_size, the service returns a nextPageToken that can be used to get the next page of results in subsequent list requests. The maximum value is 1000.
pageToken Page token. To get the next page of results, set page_token to the nextPageToken returned by a previous list request. The maximum string length in characters is 100.

Response

HTTP Code: 200 - OK

{
  "users": [
    {
      "name": "string",
      "clusterId": "string",
      "permissions": [
        {
          "databaseName": "string"
        }
      ],
      "connLimit": "string",
      "settings": {
        "defaultTransactionIsolation": "string",
        "lockTimeout": "integer",
        "logMinDurationStatement": "integer",
        "synchronousCommit": "string",
        "tempFileLimit": "integer",
        "logStatement": "string"
      },
      "login": true,
      "grants": [
        "string"
      ]
    }
  ],
  "nextPageToken": "string"
}
Field Description
users[] object

A PostgreSQL User resource. For more information, see the Developer's Guide.

users[].
name
string

Name of the PostgreSQL user.

users[].
clusterId
string

ID of the PostgreSQL cluster the user belongs to.

users[].
permissions[]
object

Set of permissions granted to the user to access specific databases.

users[].
permissions[].
databaseName
string

Name of the database that the permission grants access to.

users[].
connLimit
string (int64)

Maximum number of database connections available to the user.

When used in session pooling, this setting limits the number of connections to every single host in PostgreSQL cluster. In this case, the setting's value must be greater than the total number of connections that backend services can open to access the PostgreSQL cluster. The setting's value should not exceed the value of the Cluster.config.postgresqlConfig_12.effectiveConfig.maxConnections setting.

When used in transaction pooling, this setting limits the number of user's active transactions; therefore, in this mode user can open thousands of connections, but only N concurrent connections will be opened, where N is the value of the setting.

Minimum value: 10 (default: 50), when used in session pooling.

users[].
settings
object

PostgreSQL user settings.

users[].
settings.
defaultTransactionIsolation
string

SQL sets an isolation level for each transaction. This setting defines the default isolation level to be set for all new SQL transactions.

See in-depth description in PostgreSQL documentation.

  • TRANSACTION_ISOLATION_READ_UNCOMMITTED: this level behaves like TRANSACTION_ISOLATION_READ_COMMITTED in PostgreSQL.
  • TRANSACTION_ISOLATION_READ_COMMITTED: (default) on this level query sees only data committed before the query began.
  • TRANSACTION_ISOLATION_REPEATABLE_READ: on this level all subsequent queries in a transaction will see the same rows, that were read by the first SELECT or INSERT query in this transaction, unchanged (these rows are locked during the first query).
  • TRANSACTION_ISOLATION_SERIALIZABLE: this level provides the strictest transaction isolation. All queries in the current transaction see only the rows that were fixed prior to execution of the first SELECT or INSERT query in this transaction. If read and write operations in a concurrent set of serializable transactions overlap and this may cause an inconsistency that is not possible during the serial transaction execution, then one of the transaction will be rolled back, triggering a serialization failure.
users[].
settings.
lockTimeout
integer (int64)

The maximum time (in milliseconds) for any statement to wait for acquiring a lock on an table, index, row or other database object. If the wait time is longer than the specified amount, then this statement is aborted.

Default value: 0 (no control is enforced, a statement waiting time is unlimited).

users[].
settings.
logMinDurationStatement
integer (int64)

This setting controls logging of the duration of statements.

The duration of each completed statement will be logged if the statement ran for at least the specified amount of time (in milliseconds). E.g., if this setting's value is set to 500, a statement that took 300 milliseconds to complete will not be logged; on the other hand, the one that took 2000 milliseconds to complete, will be logged.

Value of 0 forces PostgreSQL to log the duration of all statements.

Value of -1 (default) disables logging of the duration of statements.

See in-depth description in PostgreSQL documentation.

users[].
settings.
synchronousCommit
string

This setting defines whether DBMS will commit transaction in a synchronous way.

When synchronization is enabled, cluster waits for the synchronous operations to be completed prior to reporting success to the client. These operations guarantee different levels of the data safety and visibility in the cluster.

See in-depth description in PostgreSQL documentation.

  • SYNCHRONOUS_COMMIT_ON: (default value) success is reported to the client if the data is in WAL (Write-Ahead Log), and WAL is written to the storage of both the master and its synchronous standby server.
  • SYNCHRONOUS_COMMIT_OFF: success is reported to the client even if the data is not in WAL. There is no synchronous write operation, data may be loss in case of storage subsystem failure.
  • SYNCHRONOUS_COMMIT_LOCAL: success is reported to the client if the data is in WAL, and WAL is written to the storage of the master server. The transaction may be lost due to storage subsystem failure on the master server.
  • SYNCHRONOUS_COMMIT_REMOTE_WRITE: success is reported to the client if the data is in WAL, WAL is written to the storage of the master server, and the server's synchronous standby indicates that it has received WAL and written it out to its operating system. The transaction may be lost due to simultaneous storage subsystem failure on the master and operating system's failure on the synchronous standby.
  • SYNCHRONOUS_COMMIT_REMOTE_APPLY: success is reported to the client if the data is in WAL (Write-Ahead Log), WAL is written to the storage of the master server, and its synchronous standby indicates that it has received WAL and applied it. The transaction may be lost due to irrecoverably failure of both the master and its synchronous standby.
users[].
settings.
tempFileLimit
integer (int64)

The maximum storage space size (in kilobytes) that a single process can use to create temporary files. If a transaction exceeds this limit during execution, it will be aborted.

A huge query may not fit into a server's RAM, therefore PostgreSQL will use some storage to store and execute such a query. Too big queries can make excessive use of the storage system, effectively making other quieries to run slow. This setting prevents execution of a big queries that can influence other queries by limiting size of temporary files.

users[].
settings.
logStatement
string

This setting specifies which SQL statements should be logged (on the user level).

See in-depth description in PostgreSQL documentation.

  • LOG_STATEMENT_NONE: (default) logs none of SQL statements.
  • LOG_STATEMENT_DDL: logs all data definition statements (such as CREATE, ALTER, DROP and others).
  • LOG_STATEMENT_MOD: logs all statements that fall in the LOG_STATEMENT_DDL category plus data-modifying statements (such as INSERT, UPDATE and others).
  • LOG_STATEMENT_ALL: logs all SQL statements.
users[].
login
boolean (boolean)

This flag defines whether the user can login to a PostgreSQL database.

Default value: true (login is allowed).

users[].
grants[]
string

Roles and privileges that are granted to the user (GRANT <role> TO <user>).

For more information, see the documentation.

The maximum string length in characters for each value is 63. Each value must match the regular expression [a-zA-Z0-9_]*.

nextPageToken string

This token allows you to get the next page of results for list requests. If the number of results is larger than pageSize, use the next_page_token as the value for the pageToken parameter in the next list request. Each subsequent list request will have its own next_page_token to continue paging through the results.

In this article:
  • HTTP request
  • Path parameters
  • Query parameters
  • Response
Language
Careers
Privacy policy
Terms of use
© 2021 Yandex.Cloud LLC