[pgpool-general: 3130] Re: I published an article about my pgpool2 setup

[Tatsuo Ishii]

> Hey,
> 
> after setting up pgpool2, I published an article about my setup:
> 
> http://michael.stapelberg.de/Artikel/replicated_postgresql_with_pgpool
> 
> I thought it’d be a nice gesture to point you to it, and I’d be happy
> to correct any factual mistakes that are in the article.
> 
> Thanks for your work on pgpool2,

You are welcome.

I took a look at your article.

Your setting is interesting since you enable streaming replication of
PostgreSQL and at the same time you run pgpool-II in replication
mode. Is there any reason you do not use pgpool-II's streaming
replication mode (which means master_slave_mode = on and
master_slave_sub_mode = 'stream')?

> In order to recover node 1 (alp in this case), use:
>
> pcp_recovery_node 300 localhost 9898 postgres wQgvBEusf1NWDRKVXS15Fc8 1
>
> Where 300 is the timeout for the entire recovery, so perhaps you need to increase that.

Actually there will be no effect no matter how you set the timeout. We
decided to ignore the timeout parameter of pcp command long time
ago. But for backward compatibility, we still keep on having the
parameter.

As for timeout of recovery, PostgreSQL's "statement_timeout" is more
crucial since the recovery process is executed in a C function, which
runs in a SELECT on the master PostgreSQL. In the git head (including
master and stable branches), pgpool-II executes "set statement_timeout
to 0" to disable it and will appear in the next releases (we plan to
release stable minor releases this week).

> In case the recovery fails, the only thing you’ll get back from
> pcp_recovery_node is the text “BackendError”, which is not very
> helpful. The logfile of pgpool2 contains a bit more information, but
> to debug recovery problems, I typically strace all PostgreSQL
> processes and see what the scripts are doing/where they are failing.