[Postgres-xl-developers] GTM: register.node and GTM_ERRCODE_NODE_NOT_REGISTERED

Tomas Vondra tomas.vondra at 2ndquadrant.com
Sat Jun 24 12:36:48 PDT 2017


While compiling XL on a slightly older system (with gcc 4.9.x), I got a 
bunch of warnings suggesting that we're not checking write() return 
codes in src/gtm/recover/register_common.c. I'm not sure why newer gcc 
versions fail to complain about that, but the warnings are valid.

The attached patch addresses that by adding the checks, and making sure 
we don't replace valid file with a corrupted one (where some of the 
writes failed).

What however confuses me a bit is that we never read the register.node 
file again - at least I haven't found any such place in the sources. So 
we can stop writing the file entirely, or we should read the file at GTM 
startup or something like that.

I suspect this is the cause why after a GTM restart, we get a flood of 
error messages like this:

     1:841901824:2017-06-24 21:18:19.871 CEST -LOG:
     GTM_ERRCODE_NODE_NOT_REGISTERED - node_name datanode1
     LOCATION:  GTM_HandleGlobalXmin, register_common.c:976

     1:850294528:2017-06-24 21:18:23.113 CEST -LOG:
     GTM_ERRCODE_NODE_NOT_REGISTERED - node_name datanode2
     LOCATION:  GTM_HandleGlobalXmin, register_common.c:976

The problem is that the nodes reconnect without re-registering, so the 
GTM has no idea those nodes were already connected (because we haven't 
read the register.node file).

I'm no GTM expert, but do we really need to keep the list of registered 
nodes across GTM restarts? Why can't the nodes simply re-register after 
reopening the GTM connection?


Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtm-write-check-return-code.patch
Type: text/x-patch
Size: 9127 bytes
Desc: not available
URL: <http://lists.postgres-xl.org/private.cgi/postgres-xl-developers-postgres-xl.org/attachments/20170624/4fb69af4/attachment.bin>

More information about the Postgres-xl-developers mailing list