Hi, On 2023-02-06 19:29:46 -0800, Andres Freund wrote: > There's something off. Isolationtester's control connection emits *loads* of > invalidation messages: > 2023-02-06 19:29:06.430 PST [2125297][client > backend][6/0:121864][isolation/receipt-report/control connection] LOG: > previously emitted 7662 messages, 21 this time > 2023-02-06 19:29:06.566 PST [2125297][client > backend][6/0:121873][isolation/receipt-report/control connection] LOG: > previously emitted 8155 messages, 99 this time > 2023-02-06 19:29:06.655 PST [2125297][client > backend][6/0:121881][isolation/receipt-report/control connection] LOG: > previously emitted 8621 messages, 99 this time > 2023-02-06 19:29:06.772 PST [2125297][client > backend][6/0:121892][isolation/receipt-report/control connection] LOG: > previously emitted 9208 messages, 85 this time > 2023-02-06 19:29:06.867 PST [2125297][client > backend][6/0:121900][isolation/receipt-report/control connection] LOG: > previously emitted 9674 messages, 85 this time
Ah, that's just due to setup-teardown happening in the control connection. FWIW, I see plenty of sinval resets even if I increase the sinval queue size substantially. I suspect we've increased the number of sinval messages we sent a good bit over time, due to additional syscaches. As we only process catchup interrupts while in ReadCommand(), it's not surprising that we very quickly get behind. A single statement suffices. Anyway, that's not really a correctness issue, just a performance issue. But the postgres_fdw.sql vulnerability to syscache resets seems not great. Perhaps pgfdw_inval_callback() could check if the definition of the foreign server actually changed, before dropping the connection? Greetings, Andres Freund
