| From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
|---|---|
| To: | vitus(at)wagner(dot)pp(dot)ru |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Proposal: Implement failover on libpq connect level. |
| Date: | 2015-09-07 15:32:48 |
| Message-ID: | 8cebcc80-6d93-47e2-8168-4dc9e4d08bad@mm |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-jdbc |
Victor Wagner wrote:
> It would just take a bit more time for client and a bit more load for
> server - to make sure that this connection is read-write by
> issuing
>
> show transaction_read_only
>
> statement before considering connection useful.
If the purpose of the feature is to wait for a failover to complete,
shouldn't it check for pg_is_in_recovery() rather than
transaction_read_only ?
That's because a database or user can be made read-only-on-connect
on an otherwise read-write instance by issuing
ALTER DATABASE dbname SET default_transaction_read_only TO on;
The same for a user with ALTER USER.
In that case, transaction_read_only would be OFF after connecting,
both on the master and on a slave, independantly of any failover
in progress or finished or not having occurred at all.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Teodor Sigaev | 2015-09-07 15:41:02 | Re: WIP: Access method extendability |
| Previous Message | Masahiko Sawada | 2015-09-07 15:18:16 | Re: Freeze avoidance of very large table. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Victor Wagner | 2015-09-08 04:29:32 | Re: Proposal: Implement failover on libpq connect level. |
| Previous Message | Victor Wagner | 2015-09-06 19:27:10 | Discussion summary: Proposal: Implement failover on libpq connect level. |