From: | Paul Förster <paul(dot)foerster(at)gmail(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Thomas Kellerer <shammat(at)gmx(dot)net>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Determine if postgresql cluster running is primary or not |
Date: | 2020-11-20 10:02:20 |
Message-ID: | 7D1914CE-4A9C-4A3B-91D2-22954ACC2452@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi David,
> On 20. Nov, 2020, at 10:34, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
>
> On Friday, November 20, 2020, Paul Förster <paul(dot)foerster(at)gmail(dot)com> wrote:
>
> > On 20. Nov, 2020, at 10:03, Thomas Kellerer <shammat(at)gmx(dot)net> wrote:
>
> >
> > select pg_is_in_recovery();
>
> I usually don't recommend using pg_is_in_recovery() only because a database cluster can be in recovery for other reasons. This is why I always do the following:
>
> Do any of those other reasons allow connections that could execute that function to exist?
that always depends on what your application does. An application could still select a lot of things, maybe even wrongly so, even if the cluster is in recovery mode.
That was my idea when writing this query and it's been working fine for years now.
Cheers,
Paul
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Förster | 2020-11-20 10:04:03 | Re: Determine if postgresql cluster running is primary or not |
Previous Message | Yi Sun | 2020-11-20 09:53:38 | Re: received immediate shutdown request caused cluster failover |