On Thu, Aug 18, 2022 at 9:01 AM Michael Paquier wrote:
>
> PANIC is not something you'd care about as the system would go down as
> and shared memory would be reset (right?) even if restart_on_crash is
> enabled. Perhaps it would help here to use something like a macro to
> catch and save the err
On Thu, Aug 04, 2022 at 03:27:11PM +0530, Bharath Rupireddy wrote:
> 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
On Mon, Jul 25, 2022 at 2:40 PM Michael Paquier 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
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 er
On Sat, Jul 23, 2022 at 2:29 AM Cary Huang wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, passed
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hello
The patch can be applied to PG master branch without p
Hi,
In production environments WAL receiver connection attempts to primary
may fail for many reasons (primary down, network is broken,
authentication tokens changes, primary_conn_info modifications, socket
errors and so on.). Although we emit the error message to server logs,
isn't it useful to sh
