You should initialize each database which composes Postgres-XL database cluster system. Both Coordinator and Datanode has its own database and you should initialize these database. Coordinator holds just database catalog and temporary data store. Datanode holds most of your data. First of all, you should determine how many Coordinators/Datanodes to run and where they should run. It is a good convention that you run a Coordinator where you run a Datanode. In this case, you should run GTM-Proxy on the same server too. It simplifies XL configuration and help to make workload of each servers even.

Both Coordinator and Datanode have their own databases, essentially PostgreSQL databases. They are separate and you should initialize them separately.

The GTM provides global transaction management feature to all the other components in Postgres-XL database cluster. Because the GTM handles transaction requirements from all the Coordinators and Datanodes, it is highly advised to run this in a separate server.

Before you start the GTM, you should decide followings:

When this is determined, you can initialize the GTM with the command initgtm, for example:

$ initgtm -Z gtm -D /usr/local/pgsql/data_gtm

All the parameters related to the GTM can be modified in gtm.conf located in data folder initialized by initgtm.

Then you can start the GTM as follows:

$ gtm -D /usr/local/pgsql/data_gtm

where -D option specifies working directory of the GTM.

Alternatively, the GTM can be started using gtm_ctl, for example:

$ gtm_ctl -Z gtm start -D /usr/local/pgsql/data_gtm

A GTM-Proxy is not a mandatory component of Postgres-XL cluster but it can be used to group messages between the GTM and cluster nodes, reducing workload and the number of packages exchanged through network.

As described in the previous section, a GTM-Proxy needs its own listen address, port, working directory and GTM-Proxy ID, which should be unique and begins with one. In addition, you should determine how many working threads to run. You should also use the GTM's address and port to start GTM-Proxy.

Then, you need first to initialize a GTM-Proxy with initgtm, for example:

$ initgtm -Z gtm_proxy -D /usr/local/pgsql/data_gtm_proxy

All the parameters related to a GTM-Proxy can be modified in gtm_proxy.conf located in data folder initialized by initgtm.

Then, you can start a GTM-Proxy like:

$ gtm_proxy -D /usr/local/pgsql/data_gtm_proxy

where -D specifies GTM-Proxy's working directory.

Alternatively, you can start a GTM-Proxy using gtm_ctl as follows:

$ gtm_ctl start -Z gtm_proxy -D /usr/local/pgsql/data_gtm_proxy

Before starting Coordinator or Datanode, you must configure them. You can configure Coordinator or Datanode by editing postgresql.conf file located at their working directory as you specified by -D option in initdb command.

Datanode is almost native PostgreSQL with some extensions. Additional options in postgresql.conf for the Datanode are as follows:

Although Coordinators and Datanodes shares the same binary, their configuration is a little different due to their functionalities.

Now you can start central component of Postgres-XL, Datanode and Coordinator. If you're familiar with starting PostgreSQL database server, this step is very similar to PostgreSQL.

You can start a Datanode as follows:

$ postgres --datanode -D /usr/local/pgsql/data

--datanode specifies postgres should run as a Datanode. You may need to specify -i postgres to accept connection from TCP/IP connections or edit pg_hba.conf if cluster uses nodes among several servers.

You can start a Coordinator as follows:

$ postgres --coordinator -D /usr/local/pgsql/Datanode

--coordinator specifies postgres should run as a Coordinator. You may need to specify -i postgres to accept connection from TCP/IP connections or edit pg_hba.conf if cluster uses nodes among several servers.

There are several common reasons the server might fail to start. Check the server's log file, or start it by hand (without redirecting standard output or standard error) and see what error messages appear. Below we explain some of the most common error messages in more detail.

LOG:  could not bind IPv4 address "127.0.0.1": Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

This usually means just what it suggests: you tried to start another server on the same port where one is already running. However, if the kernel error message is not Address already in use or some variant of that, there might be a different problem. For example, trying to start a server on a reserved port number might draw something like:

$ postgres -p 666
LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

A message like:

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).

probably means your kernel's limit on the size of shared memory is smaller than the work area PostgreSQL is trying to create (4011376640 bytes in this example). Or it could mean that you do not have System-V-style shared memory support configured into your kernel at all. As a temporary workaround, you can try starting the server with a smaller-than-normal number of buffers (shared_buffers). You will eventually want to reconfigure your kernel to increase the allowed shared memory size. You might also see this message when trying to start multiple servers on the same machine, if their total space requested exceeds the kernel limit.

An error like:

FATAL:  could not create semaphores: No space left on device
DETAIL:  Failed system call was semget(5440126, 17, 03600).

does not mean you've run out of disk space. It means your kernel's limit on the number of System V semaphores is smaller than the number PostgreSQL wants to create. As above, you might be able to work around the problem by starting the server with a reduced number of allowed connections (max_connections), but you'll eventually want to increase the kernel limit.

If you get an “illegal system call” error, it is likely that shared memory or semaphores are not supported in your kernel at all. In that case your only option is to reconfigure the kernel to enable these features.

Details about configuring System V IPC facilities are given in Section 18.4.1.

Although the error conditions possible on the client side are quite varied and application-dependent, a few of them might be directly related to how the server was started. Conditions other than those shown below should be documented with the respective client application.

psql: could not connect to server: Connection refused
        Is the server running on host "server.joe.com" and accepting
        TCP/IP connections on port 5432?

This is the generic “I couldn't find a server to talk to” failure. It looks like the above when TCP/IP communication is attempted. A common mistake is to forget to configure the server to allow TCP/IP connections.

Alternatively, you'll get this when attempting Unix-domain socket communication to a local server:

psql: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

The last line is useful in verifying that the client is trying to connect to the right place. If there is in fact no server running there, the kernel error message will typically be either Connection refused or No such file or directory, as illustrated. (It is important to realize that Connection refused in this context does not mean that the server got your connection request and rejected it. That case will produce a different message, as shown in Section 20.4.) Other error messages such as Connection timed out might indicate more fundamental problems, like lack of network connectivity.