[pgpool-general: 3776] Re: documentation ambiguities

[Tatsuo Ishii]

Igor,

Thank you for informative report!

> Hello,
> for about a month or so now I have been working on implementing Pgpool
> in front of a streaming cluster of Postgresql-9.3 instances, and have
> found a number of items in the documentation that likely require
> clarification; consequently, I wanted to get them out there in hopes
> of getting this fixed upstream.
> 
> Exactly which components of the heartbeat mechanism introduced in
> Pgpool-3.3 require Pgpool to run as root in order to work properly?
> When running as a non-root user i.e. Postgres, there are
> warnings/errors in the logs relating to failing to create the
> heartbeat receive socket, SO_BINDTODEVICE requires root privilege,
> etc; however, the heartbeat mechanism appears to work to the point
> where it can recognize that a primary Pgpool instance has gone away,
> and therefore tell the secondary instance to claim the virtual IP. To
> this point, one thing I did notice was that when running as Postgres
> in this case, Watchdog periodically got itself into situations where
> each node of the two Pgpool nodes deployed believed the other was
> down, resulting in a very interesting failover situation; this seems
> like rather similar behavior to another post describing a race
> condition which seems to occur when multiple Pgpool nodes are started
> in quick succession. I unfortunately was unable to reproduce the split
> brain behavior consistently, so therefore I am not entirely sure what
> is causing it at present. However, running Pgpool and therefore
> Watchdog as Root, and setting wd_heartbeat_deadtime = 120 or somesuch
> has mitigated the issue.

Usama, one of pgpool committers, is working on enhancing watchdog
toward pgpool-II 3.5. I think he has some ideas for what you studied
about watchdog.

> Another item that doesn't seem to be elaborated on is the fact that
> configuration parameters appear to be case-sensitive; this is readily
> apparent when setting delegate_ip vs delegate_IP in pgpool.conf. In
> the former case, at least under Pgpool-3.4.1 the parameter appears to
> be ignored entirely, with no corresponding log messages indicating
> that pgpool.conf encountered a parse error etc.

Pgpool-II always just ignores parameters it does not understand.

Your suggestion regarding case-sensitiveness is
interesting. PostgreSQL ignores case. May be pgpool-II should do like
PostgreSQL.

> Last but not least, it is not entirely clear what defines a backend
> error. This resulted in the main client of the database having issues
> interacting with it, due to query errors from Postgres resulting in
> the incorrect assessment by Pgpool that a failover was
> required. failover_on_backend_error = off ended up resolving this one,
> although it took several days to figure out that Pgpool's definition
> of a backend error encompassed much more than just the death of
> Postmaster.

Backend erros which could trigger failover fall into two categories
in pgpool.

1) PostgreSQL shutdown event. When PostgreSQL goes down, it returns a
   error code indicating it. If pgpool-II receives the error code, it
   triggers failover.

2) Any network error. For any reason pgpool-II cannot connect to
   PostgreSQL via network, which will trigger failover as well.

> I would be happy to update relevant documentation items pertaining to
> the above, presuming that someone isn't already working on it. Thanks
> for reading!

Thank you for the offering! No one is working on it. Could you please
go ahead?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp