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: | Raw Message | Whole Thread | 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. |