Re: [Postgres-xc-general] First-time tinkering with PostgreSQL-XC

[Michael P. <mic...@gm...>]

Hi,

On Fri, Sep 30, 2011 at 2:49 PM, Chris Angelico <ro...@gm...> wrote:

> $ gtm -D /usr/local/pgsql/data/gtm/ -p 6667 -l gtm.log &
>
You should start gtm with a minimum transaction ID value sufficient to avoid
conflicts by what has been created with initdb, which creates all the
default objects of a database in a data folder. initdb itself uses
transaction IDs up to 708 if I recall, so you need to start GTM with a value
superior than that.

Retry to start GTM with with command, it may make a difference:
gtm* -x 1000* -D /usr/local/pgsql/data/gtm/ -p 6667 -l gtm.log &

x option on GTM specifies from which transaction ID value GTM should begin
to feed all the cluster nodes.

$ tail -F /usr/local/pgsql/data/gtm/gtm.log
> $ postgres -D /usr/local/pgsql/data -p 15432 -i -X
> $ postgres -D /usr/local/pgsql/data1 -i -C
>
This looks correct.

>
> The command lines were partly derived from
> http://sourceforge.net/mailarchive/message.php?msg_id=26377904 but I
> don't really know what port numbers I should use. In
> /usr/local/pgsql/data/postgresql.conf are a number of references to
> 'port', most of them commented; the only one that's active is:
> gtm_port 6667
>
> When I tried to fire up gtm on port 6666, it immediately terminated
> without message. I assume this means that it couldn't bind to the
> port, but I have no way to confirm this.
>
It think 6666 is the default port value is by pooler on Coordinator,
therefore it may not work.

>
> There's a similar conf file in .../data1/ which I have now also edited
> to put gtm_port to 6667. Without this change, I was getting total
> inability to connect; now, I still get a lack of pooled commections.
>
> $ sudo su postgres
> $ psql
> psql (9.1beta2)
> Type "help" for help.
> postgres=# create user chris with password 'chris';
> ERROR:  Failed to get pooled connections
> PANIC:  cannot abort transaction 45, it was already committed
> server closed the connection unexpectedly
>        This probably means the server terminated abnormally
>        before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !>
>
> Meanwhile, the other logs show odd messages; mainly, complaining that
> the database was improperly shut down.
>
This was perhaps autovacuum transactions that were committing on nodes with
the same transaction ID as a past transaction. A transaction ID being
committed twice on a node makes it crash with a FATAL error.

Regards,
-- 
Michael Paquier
http://michael.otacoo.com