On 2021/02/01 16:13, Bharath Rupireddy wrote:
On Mon, Feb 1, 2021 at 12:29 PM Fujii Masao <masao.fu...@oss.nttdata.com> wrote:
On 2021/01/30 9:28, Bharath Rupireddy wrote:
On Sat, Jan 30, 2021 at 12:14 AM Fujii Masao
<masao.fu...@oss.nttdata.com> wrote:
+ /*
+ * It doesn't make sense to show this entry in the
output with a
+ * NULL server_name as it will be closed at the xact
end.
+ */
+ continue;
-1 with this change because I still think that it's more useful to list
all the open connections.
If postgres_fdw_get_connections doesn't have a "valid" column, then I
thought it's better not showing server_name NULL in the output.
Or if we don't have strong reason to remove "valid" column,
the current design is enough?
My only worry was that the statement from [1] "A cache flush should
not cause user-visible state changes."
If we follow this strictly, I'm afraid that postgres_fdw_get_connections()
itself would also be a problem because the cached connections are affected
by cache flush and postgres_fdw_get_connections() shows that to users.
I'm not sure if removing "valid" column is actually helpful for that statement.
Anyway, for now we have the following options;
(1) keep the feature as it is
(2) remove "valid" column
(2-1) show NULL for the connection whose server was dropped
(2-2) show fixed value (e.g., <dropped>) for the connection whose
server was dropped
(3) remove "valid" column and don't display connection whose server was dropped
(4) remove postgres_fdw_get_connections()
For now I like (1), but if others think "valid" column should be dropped,
I'm fine with (2). But I'd like to avoid (3) because I think that
postgres_fdw_get_connections() should list all the connections that
are actually being established. I have no strong opinion about whether
(2-1) or (2-2) is better, for now.
But the newly added function
postgres_fdw_get_connections is VOLATILE which means that the results
returned by postgres_fdw_get_connections() is also VOLATILE. Isn't
this enough, so that users will not get surprised with different
results in case invalidations occur within the server by the time they
run the query subsequent times and see different results than what
they saw in the first run?
I'm not sure about this...
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
