From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Cary Huang <cary(dot)huang(at)highgo(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add last failed connection error message to pg_stat_wal_receiver |
Date: | 2022-08-04 09:57:11 |
Message-ID: | CALj2ACV=0yfSzNuDu2e=6C6EkN7Sa7D628pf4NBitdBJ51_zCw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 25, 2022 at 2:40 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Jul 25, 2022 at 12:19:40PM +0530, Bharath Rupireddy wrote:
> > Thanks a lot Cary for reviewing. It will be great if you can add
> > yourself as a reviewer and set the status accordingly in the CF entry
> > here - https://commitfest.postgresql.org/38/3666/.
>
> Hmm. This stands for the connection error, but there are other things
> that could cause a failure down the road, like an incorrect system
> ID or a TLI-related report, so that seems a bit limited to me?
Good point. The walreceiver can exit for any reason. We can either 1)
store for all the error messages or 2) think of using sigsetjmp but
that only catches the ERROR kinds, leaving FATAL and PANIC messages.
The option (1) is simple but there are problems - we may miss storing
future error messages, good commenting and reviewing may help here and
all the error messages now need to be stored in string, which is
complex. The option (2) seems reasonable but we will miss FATAL and
PANIC messages (we have many ERRORs, 2 FATALs, 3 PANICs). Maybe a
combination of option (1) for FATALs and PANICs, and option (2) for
ERRORs helps.
Thoughts?
--
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/
From | Date | Subject | |
---|---|---|---|
Next Message | 荒井元成 | 2022-08-04 10:01:33 | RE: collate not support Unicode Variation Selector |
Previous Message | shiy.fnst@fujitsu.com | 2022-08-04 09:49:15 | RE: Introduce wait_for_subscription_sync for TAP tests |