Re: [Postgres-xc-general] JDBC driver for 0.9.4

[Lionel F. <lio...@gm...>]

To have the exact trace

==> /var/log/pgxc/coordinator.log <==
LOG:  could not create IPv6 socket: Address family not supported by protocol
LOG:  database system was shut down at 2011-05-27 10:57:27 CEST
LOG:  database system is ready to accept connections
LOG:  unexpected EOF on client connection

Lionel F.



2011/5/27 Lionel Frachon <lio...@gm...>:
> Hi,
>
>> > Have you setup correctly data_node_hosts and data_node_ports on Coordinator?
> Coordinator shows :
> num_data_nodes = 2
> num_coordinators = 1
> data_node_hosts = '10.114.12.26,10.114.12.14'
> data_node_ports = '25001,25001'
>
> (However, coordinator does not start with these options
>
> #data_node_users = pgxc
> #coordinator_users = pgxc
>
> generated through pgxc_config, so I removed them. Any importance ?)
>
> I see them connected through 'netstat -apn' on both sides, and node 2
> connected with gtm.
>
>> Have you used -i option on datanode to be sure that it can accept TCP/IP
>> remote connections and not only local ones?
>
> Yes , launch option is -i -p 25001
>
>> Perhaps it is a problem with pg_hba.conf.
> It's set to trust on local segment network, and had errors with it
> that I corrected, so assuming it's working now :) psql working
> properly on creating database remotely.
>
>> gtm_host and gtm_port are correctly set for both Coordinator and datanodes.
>
> They are :
> Node 2 :
> datanode/postgresql.conf:gtm_host = '10.114.12.26'
> datanode/postgresql.conf:gtm_port = 16680
>
> Node 1
> coord/postgresql.conf:gtm_host = '10.114.12.26'
> coord/postgresql.conf:gtm_port = 16680
> datanode/postgresql.conf:gtm_host = '10.114.12.26'
> datanode/postgresql.conf:gtm_port = 16680
>
> Of course, gtm running on 16680. And confirmed they are TCP-connected
> through netstat.
>
>> Is pgxc_node_id set differently for your datanodes?
> Yes, but doc is not crystal clear on that; are pgxc_nodes to be all
> different between coord & data nodes ? Meaning
>
> coord=1, data1=2, data2=3
> or
> coord=1, data1=1,data2=2 ?
>
> (already tried some combinations...)
>
> On first JDBC query, coordinator shows an "EOF on client connection".
>
> Thanks (and thanks to Benny for the fix, will compile in parallel the
> newest build)
>
> Lionel Frachon
>
>
>
> 2011/5/27 Michael Paquier <mic...@gm...>:
>> This may be a setting problem.
>> Have you setup correctly data_node_hosts and data_node_ports on Coordinator?
>> If your coordinator cannot connect to a backend datanode it may be this
>> problem.
>>
>> Have you used -i option on datanode to be sure that it can accept TCP/IP
>> remote connections and not only local ones?
>> Perhaps it is a problem with pg_hba.conf.
>> Have you set up this file for both nodes correctly?
>>
>> If a node complains about GTM no accessible, you may need also to check if
>> gtm_host and gtm_port are correctly set for both Coordinator and datanodes.
>>
>> You have also to take care about the node IDs used in each configuration
>> file.
>> Is pgxc_node_id set differently for your datanodes?
>>
>> On Fri, May 27, 2011 at 2:47 PM, Lionel Frachon <lio...@gm...>
>> wrote:
>>>
>>> Hi Michael,
>>>
>>> I believe this is the kind of query generated by BenchmarlSQL on the
>>> "load data" stage; trying to load a 2-node cluster yesterday
>>> (1gtm+coord+datanode, 1 datanode), only one is loaded, and the other
>>> one complains saying "No GTM snapshot available" and thus not loading
>>> anything. Table content is not accessible either from the second node.
>>> I tried to switch the preferred_node and master node settings, to try
>>> to force the writes on second node first, but without positive result.
>>> However, a std psql query distributes the work properly when issued
>>> through coordinator.
>>>
>>> I'll try to revert today to the previous build (05/18) to see if
>>> there's any behaviour difference.
>>>
>>> Any clue appeciated ^^
>>>
>>> Lionel Frachon
>>>
>>> 2011/5/26 Michael Paquier <mic...@gm...>:
>>> > Btw, if I were you I'd avoid to use multiple-value INSERT with JDBC.
>>> > Those
>>> > are queries like:
>>> > INSERT INTO table_ex VALUES (1),(2),(3),(4);
>>> > I noticed today during tests that it wasn't working properly.
>>> > However, single value INSERT and normal queries work fine.
>>> > --
>>> > Michael Paquier
>>> > http://michael.otacoo.com
>>> >
>>
>>
>>
>> --
>> Michael Paquier
>> http://michael.otacoo.com
>>
>