[pgpool-general: 2973] pcp_promote_node usecase?

[Yugo Nagata]

Hi all,

Are you using pcp_promote_node? If so, please tell me your usecase!

pgpool-II has pcp_promote_node command, which change specified backend
nodes status to 'primary', but this has some problems.
So, if there is no users of pcp_promote_node, we consider to remove
this from pgpool-II. Or not, I want to know usecases and fix
pcp_promote_node to be more usefull and suitable for the usecase.

The current pcp_promote_node works as below;

(0) This is enabled only in master-slave / streaming-replication mode.

(1) This changes pgpool-II's internal status and set the specified
    node to primary. The internal status is used in online-recovery
    and loadbalancing etc..  
** Note that this doesn't control the backend nodes themselves.**

(2) All nodes other than the new primary are detached from pgpool-II.

(3) pgpool-II execute follow_master command for all the detached nodes.
    follow_master command is mainly used for auto-recovery of standbys
    from the new primary.

Here, I found the some problems:

(a) Even when DISALLOW_TO_FAILOVER is used, backends node are detached
    at step (2).
(b) If pcp_recovery_node is executed in follow_master command at step (3), 
    recovery can fail because pgpool-II's internal status can be different
    from the acutual backend status of primary/standby.

I want to fix about (a), if there is any user of pcp_promote_node.
I think the design would be:
 - When DISALLOW_TO_FAILOVER is used, pcp_promote_node is disabled
   because this command can detach some backend nodes.
 - or, pcp_promote_node change primary node status, but doesn't detach
   any nodes. (In this case, some trick would be required so that 
   primary node should be unique.)

About (b), I think this is a restriction of pgpool-II. User have
to note that internal status can be different from the acutual backend
status of primary/standby, after using pcp_promote_node. If you know
other idea, please tell me.

Any comment and suggestion?


Best regards,
-- 
Yugo Nagata <nagata at sraoss.co.jp>