Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable.
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby"GUC pseudo-variable. |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F6FD499@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.
|
Список | pgsql-hackers |
From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > I didn't look at exactly how you tried to do that, but GUCs whose values > depend on other GUCs generally don't work well at all. transaction_read_only and transaction_isolation depends on default_transaction_read_only and default_transaction_isolationrespectively. But I feel you are concerned about something I'm not aware of. Could you shareyour worries? I haven't found a problem so far. > >> * Its value is false during recovery. > > [ scratches head... ] Surely this should read as "true" during recovery? Ouch, you are right. > Also, what happens if the standby server goes live mid-session? The clients will know the change of session_read_only when they do something that calls RecoveryInProgress(). Currently,RecoveryInProgress() seems to be the only place where the sessions notice the promotion, so I set session_read_onlyto the value of default_transaction_read_only there. I think that there is room for discussion here. Itwould be ideal for the sessions to notice the server promotion promptly and notify the clients of the change. I have noidea to do that well. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: