STKEEPER_DISABLE_ALTER_SYSTEM option

[ghost]

STKEEPER_DISABLE_ALTER_SYSTEM option final and working solution for issue https://github.com/sorintlab/stolon/issues/683 and following wrong approach in pull https://github.com/sorintlab/stolon/pull/689

[lawrencejones]

Fwiw, wanting to run alter system commands is a use case we've encountered a few times now. I can't speak to the citrus extension, but we occasionally want to verify the effect of a change on just the primary/replica first before rolling it out across the cluster.

You make a good point though- the average stolon user probably shouldn't enable alter system for the reasons you mention. We should adapt the docs to make it clear this isn't recommended.

[ghost]

@lawrencejones thanks for reviewing, the feedback was pretty clear :) @sgotti thanks for feedback, I've just added more documentation to the option from #343, you're right, I've just tested now and saw that citus doesn't run alter system if not needed, I wasn't able to make citus work at first time because it enable ssl but it also create certificates automatically, so adding pgParameters at startup (before running the create extension citus command) was failing (no certificate). But I had to make certificate myself and add pgParameters at startup to make restart working. So, finally this option was not required, or maybe to test or see the result of create extension citus in a first time. So I'm changing doc/postgres_parameters.md according to @lawrencejones comment on this feature utility

[ghost]

semaphoreci ununderstandable build failed see https://github.com/sorintlab/stolon/issues/690

[sgotti]

@idetoile @lawrencejones Using a keeper option will require a keeper restart. Is this ok for you?Another way will be to use a clusterspec option. Alter system will be enabled for all the instances but you'll execute it only on the instance you want and won't require a restart.

[ghost]

This is ok for me. The first approach I was trying was based clusterspec https://github.com/sorintlab/stolon/pull/689 but that was breaking many unit testings and had introduced strange and incomprehensible bugs. My level in golang (I just begin) was not enough to fix it, so I finally came to keeper approach and thought that was the best one, your feedback indicating me that is not, but for me it's sufficient.