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
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)
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 -
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
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,
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
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
