PostgreSQL connector

The PostgreSQL connector supports all modern versions of PostgreSQL from version 9.x up.

It fully supports SSL/TLS connections from database clients if a valid certificate and private key are provided in the project.

Parameters

This connector takes the following parameters:

Connection name

Can be any name you want.

Active

If checked, then this connection will be active any time Gallium Data is running, meaning that the local port will be open and listening for requests. If you uncheck this (and then click Publish), then the connection is "commented out" -- it's as if it didn't exist, but you can still keep it around for later.

Type

The type of database for this connection. This is selected when you create the connection and cannot be changed afterwards.

Server host

The name or address of the database server. This can be a partial name (like dbserver), a full name (like dbserver.it.acme.com), an IP4 address (like 181.77.230.42) or an IP6 address if your network supports IP6 (e.g. 266a:1790:2920:69e0:35c:d8ac:da8e:15e0). 

If you are running Gallium Data as a Docker container, and the database server is on the host machine, you can use host.docker.internal (on Windows or Mac, but see here for Linux).

Local address

The address on which to listen for requests. This is typically only relevant if your server has more than one address. If left blank, Gallium Data will listen on all addresses (which is equivalent to 0.0.0.0).

Server port

The port on the database server. For Postgres, it's usually 5432.

Local port

The port number in the Gallium Data container that will be listening to requests from database clients.

Use SSL to server

whether to use SSL when connecting to the database server. There are three options:

• never: disables SSL completely when talking to the server

• always: always use SSL when talking to the server

• on request: use SSL if the client uses SSL

Note that, if you want to use SSL (i.e. either always or on request), the database server's certificate must be trusted by Gallium Data, meaning that either the database server uses a certificate that is signed by a well-known certificate authority, or the certificate is installed in the Gallium Data project's trust (under Project > Properties). You can also use the Trust server certificate option (see below).

Use SSL to client

Similarly, three values are possible:

• never: disable SSL from clients, SSL connection attempts will be rejected

• always: always require SSL for client connections, non-SSL connections will be rejected

• on request: accept SSL connections from clients, as well as non-SSL requests

If you use always or on request, you must install a private key, as well as any certificates going with it, in the project's key area (under Project > Properties).

Trust server certificate

Whether to accept the Postgres server's SSL certificate at face value, or not. If this is false, and SSL is required, then the Postgres server's certificate will be verified, either by being signed by a well-known certificate authority, or by verifying it with the chain of certificates provided in the project's Trust entry. If this is true, then the Postgres server's SSL certificate will be accepted without verification.

Timeout to server

This specifies the number of milliseconds to wait when establishing a connection to the database server. The default value (10 seconds) is usually adequate for most cases.

Result set batch size (rows)

If set, result sets will be processed in batches of rows, and regular result set filters will not be invoked -- only result set batch filters (if any). This number indicates the largest number of rows in batches. The actual batches may contain fewer rows if the end of the result set has been reached, or if the Result set batch size (bytes) parameter is also specified.

Typical values are between 10 and 1000. Very large values may require more heap allocated to the JVM, and will negatively affect latency.

Result set batch size (bytes)

If set, result sets will be processed in batches, and regular result set filters will not be invoked -- only result set batch filters (if any). This number indicates approximately the largest amount of memory that a batch should grow to before it is submitted to the response filters. The actual batches may contain fewer rows if the end of the result set has been reached, or if the Result set batch size (rows) parameter is also specified.

Typical values are between 1000 and 1000000. Very large values may require more heap allocated to the JVM, and will negatively affect latency.