Would you please provide the situation when target_session_attrs are useful?

For example when Config DB is PG cluster and you want to set it to read-write node. Host field accepts currently already multiple hosts if you supply them and separate by comma. Connection String will be built out of the parameters supplied. However target_session_attrs is not supplied and its default value is 'any' if not supplied.
https://www.postgresql.org/docs/current/libpq-connect.html

target_session_attrs
This option determines whether the session must have certain properties to be acceptable. It's typically used in combination with multiple host names to select the first acceptable alternative among several hosts. There are six modes:

any (default)
any successful connection is acceptable

In our environment I have set up 2 pgwatch machines, one per site, they share config DB and it is clustered. Web is accessible on both nodes. PgWatch2 service itself I unfortunately have to stop and start depending on which site is mainly active. It is more in case something would happen to one site, then I can easily start monitoring service on machine located in 2nd site.

After that change I can connect to Config DB RW node when provide those options in pgwatch2-webui.service file.

[Service]
Environment="PW2_PGHOST=pgwatch11.krisavi.intra,pgwatch21.krisavi.intra"
Environment="PW2_PGDATABASE=pgwatch2_config"
Environment="PW2_PGUSER=pgwatch2"
Environment="PW2_TARGET_SESSION_ATTRS=read-write"
...

Maybe the Environment variable should be named to PW2_PGTARGET_SESSION_ATTRS just to align with other of it's PG related variables.

I would suggest not to have the new PW2_TARGET_SESSION_ATTRS variable at all as this is a pretty rare case and we already have too many :D Just add target_session_attrs='read-write' to the connect string if psycopg2.__libpq_version__ >= 100000, i.e. if session attributes are supported at all.

This approach would accepts a certain risk when all nodes are degraded to standby for a while...but still OK I think as the config DB / UI is not operationally critical compared to the metrics collector - which does actually configuration caching to handle short config file / DB downtimes.

Would you please resolve conflicts? It's probably introduced by #646

OK, will resolve the conflict that other PR caused.

I added row to documentation as well about read-write being default.

Thanks