[pgpool-general: 8527] Re: "delay_threshold_by_time" not detecting replication lag

Tatsuo Ishii ishii at sraoss.co.jp
Wed Dec 28 08:16:55 JST 2022


> I wrote a "capture" script that runs several commands/queries to
> demonstrate this issue
> Script uses the query you requested (except I added the entire
> replay_lag columns also)
> The script followed by the output is below and it shows:
> * when replay lag was 56+ seconds (according to pg_stat_statements),
> the output from SHOW POOL_NODES and from pcp_node_info showed no delay
> * there was no entry in the log showing replication log threshold being exceeded
> 
> SCRIPT:
[snip]
> OUTPUT:
> 
> [postgres at localhost]$ ./check_lag.sh
> 
> 
> 2022-12-27T15:18:55+00:00 | checking lag on primary directly via
> pg_stat_replication...
>  application_name |   state   | sync_state |   int4   |   replay_lag
> ------------------+-----------+------------+----------+-----------------
>  walreceiver      | streaming | async      | 56663201 | 00:00:56.663201
> (1 row)

It seems application_name is "walreceiver", which is different from
your pgpool.conf:

> backend_application_name1 = 'pg-2'

Pgpool-II checks the application name when delay_threshold_by_time >
0. If the result of pg_stat_replication.application_name does not
match, replay_lag will be ignored. Check your primary_conninfo in
postgresql.conf of the standby node to see whether application_name is
properly set.

Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp


More information about the pgpool-general mailing list