[ClusterLabs] OCF_HEARTBEAT_PGSQL - any good with current Postgres- ?

[lejeczek]

On 05/05/2023 10:41, Jehan-Guillaume de Rorthais wrote:
> On Fri, 5 May 2023 10:08:17 +0200
> lejeczek via Users <users at clusterlabs.org> wrote:
>
>> On 25/04/2023 14:16, Jehan-Guillaume de Rorthais wrote:
>>> Hi,
>>>
>>> On Mon, 24 Apr 2023 12:32:45 +0200
>>> lejeczek via Users <users at clusterlabs.org> wrote:
>>>   
>>>> I've been looking up and fiddling with this RA but
>>>> unsuccessfully so far, that I wonder - is it good for
>>>> current versions of pgSQLs?
>>> As far as I know, the pgsql agent is still supported, last commit on it
>>> happen in Jan 11th 2023. I don't know about its compatibility with latest
>>> PostgreSQL versions.
>>>
>>> I've been testing it many years ago, I just remember it was quite hard to
>>> setup, understand and manage from the maintenance point of view.
>>>
>>> Also, this agent is fine in a shared storage setup where it only
>>> start/stop/monitor the instance, without paying attention to its role
>>> (promoted or not).
>>>   
>> It's not only that it's hard - which is purely due to
>> piss-poor man page in my opinion - but it really sounds
>> "expired".
> I really don't know. My feeling is that the manpage might be expired, which
> really doesn't help with this agent, but not the RA itself.
>
>> Eg. man page speaks of 'recovery.conf' which - as I
>> understand it - newer/current versions of pgSQL do not! even
>> use... which makes one wonder.
> This has been fixed in late 2019, but with no documentation associated :/
> See:
> https://github.com/ClusterLabs/resource-agents/commit/a43075be72683e1d4ddab700ec16d667164d359c
>
> Regards,

Right.. like the rest of us admins/users going to the code 
is the very first thing we do :)
RA/resource seems to work but I sincerely urge the 
programmer(s)/author(s) responsible, to update man pages so 
they reflect state of affairs as of today - there is nothing 
more discouraging - to the rest of us sysadmins/endusers - 
than man pages which look like stingy conservatives 
programmer's note.
What setup of this RA does, is misleading in parts - still 
creates config part in a file called 'recovery.conf'

on that note - does this RA not require way to much open 
pgSQL setup, meaning not very secure? Would anybody know?
I cannot see - again ! regular man pages and not the code - 
how replication could be secured down by not using user 
'postgres' itself and then perhaps adding authentication 
with passwords, at least.

many thanks, L.