Re: is pg_log_standby_snapshot() really needed?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: is pg_log_standby_snapshot() really needed?
Date: 2023-06-07 23:02:49
Message-ID: 20230607230249.kgzd2mucs4iuxnl3@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-06-07 13:50:30 -0500, Jaime Casanova wrote:
> CHECKPOINT could be expensive in a busy system, but the problem
> pg_log_standby_snapshot() is solving is about a no-activity system,
> and in a no-activity system CHECKPOINT is very fast.

There's no easy way for the subscriber to know if the system is active or
not. The only realistic way is to unconditionally issue the relevant
command. And that's not at all ok for CHECKPOINT.

> Even with very low activity SUBSCRIPTION flows fine. As an example I
> put an INSERT happening every 10s and SUBSCRIPTION never stuck no
> CHECKPOINT nor pg_log_standby_snapshot() needed.

Nobody forces you to issue pg_log_standby_snapshot(). If things work fine
without it for you, cool. But it's pretty trivial to see that it doesn't
always:

With pg_log_standby_snapshot() as normal,
recovery/035_standby_logical_decoding takes 15.63s on my machine. Without it I
lost patience after 2 minutes. And the test was only at the start (8 out of 78
subtests).

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii.Yuki@df.MitsubishiElectric.co.jp 2023-06-07 23:08:54 RE: Partial aggregates pushdown
Previous Message Jeff Davis 2023-06-07 22:43:14 Re: pg_collation.collversion for C.UTF-8