Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kflvx-0003HJ-GR for pljava-dev@arkaria.postgresql.org; Thu, 19 Nov 2020 15:33:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kflvw-0004Cq-G2 for pljava-dev@arkaria.postgresql.org; Thu, 19 Nov 2020 15:33:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kflmj-0001da-Eh for pljava-dev@lists.postgresql.org; Thu, 19 Nov 2020 15:23:45 +0000 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kflmc-0005A2-Td for pljava-dev@lists.postgresql.org; Thu, 19 Nov 2020 15:23:44 +0000 Received: by mail-ot1-x331.google.com with SMTP id y24so58489otk.3 for ; Thu, 19 Nov 2020 07:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Fn9v4BMPFsQpULnuPfBug61OKh1zZlElIZ72eoCnk14=; b=NiANp7FkJwDIZnE1ZBc6XICLkDy7rTu9/4F3jiu9+HmLf9O4zoxc5+jOepLHXQ/hJL SlXgUkF2J5zr1o2lZAgsX6RMMmYjOIlUWM67ghTwCPfc0D9Ge9izNUc/wJrjGgD7U9FX b+EsfWPErgPbYuraT9FkX1eXgMYoYiCvtUkIy2ItGL/3wEaZ7My/5HSKNbF+HY3Qiomm U1kOthTx+oyTkWELvSg0dQqzNq0ZDN3uwoE5jgdrMSbRcCnViLBYWHKnnBZWUNe9UMeU qLqyaXTFrfY9gdCdfKDGCIDvUBuIrQbWQybYO/qrsaC+EGo8Nm35mNmMzqG9aFN/0wPN bK9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Fn9v4BMPFsQpULnuPfBug61OKh1zZlElIZ72eoCnk14=; b=DnIaH8681NjzRkt1EF0OQsxSFZ/PrCS3rnREGDsPPNeN0PHeQoHKFRFCyW2weac4gS GlsLxm9rYafJ0/JSHS0iJkz+R4MkGHfnTHMzK9jjWrMhSkBhRAVvHwj7EpM7OlVbUXFz kJotdSmzvMU8NG0EA+7MWie7Yizu4tFGQqxn+8FeFSJWQb6aAPdA9sk8NmaAI9VrcQrU bkwXJnhJONp5SLAuWKpw7FnBvmFkaSGf8UD7ckDLPRXpagQAaeWNGW/p4aeOmFbwmOWh sLbMtlN1tWKbVqriQInIY48mNT6YniLmeLgVYE7sdPckcKzD9S0pGD+2CwwgoB93Kt4O /lAA== X-Gm-Message-State: AOAM533pyllUeWBraNKfM1kF4AqNiFCcjYOXkdfjqjzviznAEqFrN4on /gdbYlsPEm2dv8cLD5mwj2Moi/LDHYqc7QhdnWtJvbIeP8filA== X-Google-Smtp-Source: ABdhPJylh5KTFW810IzISB9Iby64MTZR4RpdqHBy35+oLrt08jLcXHTkl1BR74jgLRD/LdzCV69zTkfFQIxTeQW1pkI= X-Received: by 2002:a9d:3f49:: with SMTP id m67mr4765482otc.78.1605799417734; Thu, 19 Nov 2020 07:23:37 -0800 (PST) MIME-Version: 1.0 From: Erik Mata Date: Thu, 19 Nov 2020 16:23:26 +0100 Message-ID: Subject: Fail to create distributed table in Citus To: pljava-dev@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000dfebe005b4774f40" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000dfebe005b4774f40 Content-Type: text/plain; charset="UTF-8" I have set up a local docker environment with a total of 4 Postgres server instances, all including Citus (9.5.0) and PL/JAVA (1.6.1) extensions: - 1 as Citus master - 3 as Citus workers I have set up a simple routine in PL/JAVA which creates a table and requests that the table be distributed in the cluster, as: CREATE TABLE test1 (a BIGINT PRIMARY KEY); SELECT create_distributed_table('test1', 'a', colocate_with=>'none'); I connect to the Citus master server via a JDBC-connection to localhost. I then call the PL/JAVA routine, as: SELECT test_create_distributed_table(); This results in a local table being created on the Citus master node, but no tables are created on the workers and the Citus utility functions tell me that the table is NOT distributed. If I use the same statements that I have included in the PL/JAVA routine (see above), but I execute them from within e.g. DataGrip, connected to the Citus master node, the table is created and distributed correctly. I can see that the correct tables are created on the workers and the Citus utility functions tell me that the table is indeed distributed. So, it seems that there is nothing wrong with my setup (cluster). The problem, as far as I can tell, should be somewhere in how PL/JAVA connects to the Citus master node. The PL/JAVA routine runs in a JVM that is spawned by the Postgres server process on the Citus master node. The PL/JAVA routine acquires a connection to the local database via a somewhat fake JDBC-connection (jdbc:default:connection) as explained in the PL/JAVA documentation. I suspect that this fake JDBC-connection is the reason that the Citus master node is unable to distribute the table to the rest of the cluster nodes. As a side-note: From within PL/JAVA routines, I am able to execute other types of statements that interact with distributed tables created outside of the PL/JAVA routine. I am able to DROP, TRUNCATE, INSERT, UPDATE, DELETE etc. Just not SELECT create_distributed_table. Any help is appreciated! --000000000000dfebe005b4774f40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have set up a local docker environment with a total of 4= Postgres server instances, all including Citus (9.5.0) and PL/JAVA (1.6.1)= extensions:
- 1 as Citus master
- 3 as Citus workers

I have set up a simple routine in PL/JAVA which creates a= table and requests that the table be distributed in the cluster, as:

CREATE TABLE test1 (a BIGINT PRIMARY KEY);
SELECT create_distributed_table('test1', 'a', colocat= e_with=3D>'none');

I connect to the Cit= us master server via a JDBC-connection to localhost.
I then call = the PL/JAVA routine, as:

SELECT test_create_distributed_table();

This results in a local table being created on the Ci= tus master node, but no tables are created on the workers and the Citus uti= lity functions tell me that the table is NOT distributed.

If I use the same statements that I have included in the PL/JAVA ro= utine (see above), but I execute them from within e.g. DataGrip, connected = to the Citus master node, the table is created and distributed correctly. I= can see that the correct tables are created on the workers and the Citus u= tility functions tell me that the table is indeed distributed.
So, it seems that there is nothing wrong with my setup (cluste= r).

The problem, as far as I can tell, should be s= omewhere in how PL/JAVA connects to the Citus master node. The PL/JAVA rout= ine runs in a JVM that is spawned by the Postgres server process on the Cit= us master node. The PL/JAVA routine acquires a connection to the local data= base via a somewhat fake JDBC-connection (jdbc:default:connection) as expla= ined in the PL/JAVA documentation.

I suspect that = this fake JDBC-connection is the reason that the Citus master node is unabl= e to distribute the table to the rest of the cluster nodes.

<= /div>
As a side-note: From within PL/JAVA routines, I am able to execut= e other types of statements that interact with distributed tables created o= utside of the PL/JAVA routine. I am able to DROP, TRUNCATE, INSERT, UPDATE,= DELETE etc. Just not SELECT create_distributed_table.

=
Any help is appreciated!
--000000000000dfebe005b4774f40--