[Pgpool-hackers] Patch to avoid crashes after adding new node in Master/Slave mode

[Gurjeet Singh]

Hi,

    The ability to add new slave nodes, without requiring a restart was
added in commit [1].

    One problem that was overlooked was that in main(), when initializing
my_backend_status[], only NUM_BACKENDS number of elements of that array are
initialized and used for the rest of the life of the pool_worker_child
process. Since the NUM_BACKEDS increases everytime a new slave backend is
added, but the corresponding element in the private array is still NULL, the
pool_worker_child crashes when trying to check VALID_BACKEND(i) in
establish_persistent_connection().

    The attached micro patch avoids the crashes by initializing the private
array's all MAX_NUM_BACKENDS instead of just NUM_BACKENDS.

    This will also avoid crashes of pcp_attach_node when it tries to check
VALID_BACKEND() in send_failback_request(). It crashes because, same as
above, its private array is initialized only up to NUM_BACKENDS and the ID
of the new slave node being attached is greater than current NUM_BACKENDS.

    The bigger concern, which this patch does not address, is that of
keeping my_backend_status[] up-to-date in pool_worker_child process and any
other auxiliary processes.

Regards,

[1]
http://lists.pgfoundry.org/pipermail/pgpool-committers/2011-May/001749.html
-- 
Gurjeet Singh
EnterpriseDB Corporation
The Enterprise PostgreSQL Company
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/pgpool-hackers/attachments/20110819/90be53bc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: private_backend_status.patch
Type: text/x-diff
Size: 480 bytes
Desc: not available
URL: <http://pgfoundry.org/pipermail/pgpool-hackers/attachments/20110819/90be53bc/attachment.bin>