Re: Multiple hosts in connection string failed to failover in non-hot standby mode
От
Michael Paquier
Тема
Re: Multiple hosts in connection string failed to failover in non-hot standby mode
Дата
Msg-id
YJox0BbKVt8rCZ4S@paquier.xyz
Ответ на
Список
Дерево обсуждения
Multiple hosts in connection string failed to failover in non-hot standby mode Hubert Zhang <zhubert@vmware.com>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Noah Misch <noah@leadboat.com>
RE: Multiple hosts in connection string failed to failover in non-hot standby mode "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Hubert Zhang <zhubert@vmware.com>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Tom Lane <tgl@sss.pgh.pa.us>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Tom Lane <tgl@sss.pgh.pa.us>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Tom Lane <tgl@sss.pgh.pa.us>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Hubert Zhang <zhubert@vmware.com>
Re: Multiple hosts in connection string failed to failover in non-hot standby mode Tom Lane <tgl@sss.pgh.pa.us>
RE: Multiple hosts in connection string failed to failover in non-hot standby mode "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
On Thu, May 06, 2021 at 01:22:27PM -0400, Tom Lane wrote: > Hm. I'd debated whether to clear conn->errorMessage at the end of > a successful connection sequence, and decided not to on the grounds > that it might be interesting info (eg it could tell you why you > ended up connected to server Y and not server X). But perhaps > it's too much of a compatibility break for this small benefit. > > I'm curious though why it took this long for anyone to complain. > I'd supposed that people were running sqlsmith against HEAD on > a pretty regular basis. FWIW, I think that the case of getting some information about any failed connections while a connection has been successfully made within the scope of the connection string parameters provided by the user is rather thin, and I really feel that this is going to cause more pain to users than this is worth it. So my vote would be to clean up conn->errorMessage after a successful connection. Now, I would not mind either if we finish by taking a decision here after beta1, to see if there are actual complains on the matter based on the feedback we get. -- Michael
В списке pgsql-hackers по дате отправления
От: tanghy.fnst@fujitsu.com
Дата: