<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">< cut steps for adding a new backend ><br>
7) optionaly you can remove backend 1 configuration<br>
   parameters. "status" columbn of show pool_nodes will be "unused" after<br>
   restarting pgpool.</blockquote><div><br></div><div>We've tried leaving holes in the numbering initially, but something didn't work out as expected. Unfortunately, I don't remember the exact problem. Maybe it had to do with each node also running a pgpool instance and gaps were not allowed in the watchdog config (like hostname0)? I'll try a build without the renumbering and report back with the findings. If we can indeed leave gaps in the backend numbering, that would probably fix the issue for us. I'm not yet sure what to do with the watchdogs though.</div></div></div></blockquote><div><br></div><div>We've just completed a full test run where we use a stable numbering (possibly with gaps) for backends and a contiguous numbering for the watchdogs and all tests pass. This does have the disadvantage that a watchdog may get a different number in the configuration than the backend running on the same node, but this is mostly cosmetically. This solves this issue for us.</div><div><br></div><div>The other question does still remain open though: Why does the auto_failback not reattach backend 1 when it detects the database is up and streaming? Could this have been related to the inconsistent numbering of the backends? I was under the impression that pgpool should always reattach a detached  backend when it is streaming from the primary.</div><div><br></div><div>Best regards,</div><div>Emond</div></div></div>