Re: [HACKERS] Patch: Implement failover on libpq connectlevel.
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: [HACKERS] Patch: Implement failover on libpq connectlevel. |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F6413C9@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: [HACKERS] Patch: Implement failover on libpq connect level. (Craig Ringer <craig@2ndquadrant.com>) |
Список | pgsql-jdbc |
From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Craig Ringer > >> If true, that's insane. That can be different on each connection to > >> the cluster and can change tens of thousands of times per second on > >> any connection! > > > > I don't think that's insane. The command is only being issued at > > connection startup, and will only be different on different > > connections if it's been configured that way. > > I agree. However, I also think we should make sure add a GUC_REPORT var > in v10 that lets a client tell whether it's connected to a read/write or > read-only node right from the start. This will save an unnecessary > round-trip and some annoying log-spam. Yes, I meant the GUC_REPORT method. I don't think something like read-only and read/write is intuitive as values valuesof target_server_type, because people who want to use reporting apps that use temporary tables have to connect to theprimary, because temp tables are not supported on standbys. I think the current notion of primary/standby is good; thosewho require temp tables need to specify primary. > I'd rather not bind it directly to "in recovery" because we're likely to > want to support read-only logical replication nodes in future, but even > that would be OK. Maybe we should determine the name and value of the connection parameter and GUC-REPORTed variable in light of the logicalreplication. Regards Takayuki Tsunakawa
В списке pgsql-jdbc по дате отправления: