Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away
Date
Msg-id CALj2ACU4yGdJ_a5ikuq_VdX4uJBph2S_bWE1bNhXNPEn-MCV0w@mail.gmail.com
Whole thread Raw
In response to Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away
List pgsql-hackers
On Thu, Oct 1, 2020 at 8:10 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
> pg_stat_clear_snapshot() can be used to reset the entry.
>

Thanks. I wasn't knowing it.

>
> +               EXIT WHEN proccnt = 0;
> +    END LOOP;
>
> Isn't it better to sleep here, to avoid th busy loop?
>

+1.

>
> So what I thought was something like
>
> CREATE OR REPLACE PROCEDURE wait_for_backend_termination()
> LANGUAGE plpgsql
> AS $$
> BEGIN
>      LOOP
>          PERFORM * FROM pg_stat_activity WHERE application_name = 'fdw_retry_check';
>          EXIT WHEN NOT FOUND;
>          PERFORM pg_sleep(1), pg_stat_clear_snapshot();
>      END LOOP;
> END;
> $$;
>

Changed.

Attaching v8 patch, please review it.. Both make check and make
check-world passes on v8.

I have another question not related to this patch: though we have
wait_pid() function, we are not able to use it like
pg_terminate_backend() in other modules, wouldn't be nice if we can
make it generic under the name pg_wait_pid() and usable across all pg
modules?


With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Should walsernder check correctness of WAL records?
Next
From: Anastasia Lubennikova
Date:
Subject: Re: [PATCH] Automatic HASH and LIST partition creation