[ClusterLabs] Antw: [EXT] unexpected fenced node and promotion of the new master PAF ‑ postgres

[Jehan-Guillaume de Rorthais]

Hi,

On Wed, 14 Jul 2021 07:58:14 +0200
"Ulrich Windl" <Ulrich.Windl at rz.uni-regensburg.de> wrote:
[...]
> Could it be that a command saturated the network?
> Jul 13 00:39:28 ltaoperdbs02 postgres[172262]: [20-1] 2021-07-13 00:39:28.936
> UTC [172262] LOG:  duration: 660.329 ms  execute <unnamed>:  SELECT
> xmf.file_id, f.size, fp.full_path  FROM ism_x_medium_file xmf  JOIN#011
> ism_files f  ON f.id_file = xmf.file_id  JOIN#011 ism_files_path fp  ON
> f.id_file = fp.file_id  JOIN ism_online o  ON o.file_id = xmf.file_id  WHERE
> xmf.medium_id = 363 AND  xmf.x_media_file_status_id = 1  AND
> o.online_status_id = 3    GROUP BY xmf.file_id, f.size,  fp.full_path   LIMIT
> 7265 ;

I doubt such a query could saturate the network. The query time itself isn't
proportional to the result set size.

Moreover, there's only three fields per row and according to their name, I
doubt the row size is really big.

Plus, imagine the result set is that big, chances are that the frontend will
not be able to cope with it as fast as the network, unless the frontend is doing
nothing really fancy with the dataset. So the frontend itself might saturate
before the network, giving some break to the later.

However, if this query time is unusual, that might illustrate some pressure on
the server by some other mean (CPU ? MEM ? IO ?). Detailed metrics would help.

Regards,