[pgpool-general: 8582] Re: PgPool thinks node 0 is in recovery.

Ron ronljohnsonjr at gmail.com
Thu Feb 2 00:58:57 JST 2023


Attached are three log files (pgpool, the primary and replicated servers).

The primary is definitely not in replication mode.

On 2/1/23 00:04, Tatsuo Ishii wrote:
>> There must have been a miscommunication; I thought I attached my
>> pgpool.conf and the log file to a previous email, but maybe not.
>>
>> I fixed the backend_port0 problem last week.
> Ok.
>
>> pgppol is already running with pgpool.conf log_min_messages=debug3. Is
>> that sufficient?
> Yes.
>
>> Attached is the error log from when I last started pgpool, and the
>> pgpool.conf from that time.
> I see some errors with streaming replication check process:
>
> 2023-01-26 13:31:04.594: sr_check_worker pid 796880: DEBUG:  do_query: extended:0 query:"SELECT pg_current_wal_lsn()"
> 2023-01-26 13:31:04.594: sr_check_worker pid 796880: CONTEXT:  while checking replication time lag
> 2023-01-26 13:31:09.594: health_check1 pid 796881: DEBUG:  health check: clearing alarm
> 2023-01-26 13:31:09.603: health_check1 pid 796881: DEBUG:  authenticate kind = 10
> 2023-01-26 13:31:09.612: health_check1 pid 796881: DEBUG:  SCRAM authentication successful for user:pool_health_check
> 2023-01-26 13:31:09.612: health_check1 pid 796881: DEBUG:  authenticate backend: key data received
> 2023-01-26 13:31:09.612: health_check1 pid 796881: DEBUG:  authenticate backend: transaction state: I
> 2023-01-26 13:31:09.612: health_check1 pid 796881: DEBUG:  health check: clearing alarm
> 2023-01-26 13:31:09.612: health_check1 pid 796881: DEBUG:  health check: clearing alarm
> 2023-01-26 13:31:14.595: sr_check_worker pid 796880: FATAL:  Backend throw an error message
> 2023-01-26 13:31:14.595: sr_check_worker pid 796880: DETAIL:  Exiting current session because of an error from backend
> 2023-01-26 13:31:14.595: sr_check_worker pid 796880: HINT:  BACKEND Error: "recovery is in progress"
> 2023-01-26 13:31:14.595: sr_check_worker pid 796880: CONTEXT:  while checking replication time lag
>
> sr_check_process tried to dtermin WAL LSN on backend0 by issuing
> "SELECT pg_current_wal_lsn()" to backend0 but failed with:
>
>> 2023-01-26 13:31:14.595: sr_check_worker pid 796880: HINT:  BACKEND Error: "recovery is in progress"
> This suggests that backend0 is running as a standby server. I guess
> there's something wrong with the setting in backend0.  Maybe
> standby.signal exists?  Can you share PostgreSQL log of backend0 at
> it's start up?
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp

-- 
Born in Arizona, moved to Babylonia.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgpool.log
Type: text/x-log
Size: 58298 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20230201/647a669c/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FISPCCPGS405a_postgresql-2023-02-01_10.log
Type: text/x-log
Size: 1434 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20230201/647a669c/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FISPCCPGS405b_postgresql-2023-02-01_10.log
Type: text/x-log
Size: 2401 bytes
Desc: not available
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20230201/647a669c/attachment-0005.bin>


More information about the pgpool-general mailing list