Re: Unexpected cross-database vacuum impact with hot_standby_feedback=on

From: Owen Stephens <owen(at)owenstephens(dot)co(dot)uk>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Unexpected cross-database vacuum impact with hot_standby_feedback=on
Date: 2023-05-22 11:36:22
Message-ID: CANOh7gGqGaUpnT+GGeTeX+FdO-Vs+jcjqb8A_9mOop028H7h-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, May 19, 2023 at 9:50 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> Yes, that's what I would expect. There is only one "backend_xmin" in
> "pg_stat_replication", which corresponds to the snapshot held by the oldest
> query in any database on the standby server.
>

Thanks for the pointer to pg_stat_replication.

In my situation there aren't any queries against the standby server, both
queries are running against the primary, but backend_xmin does contain the
open
transaction's txid_current() value. Does the standby somehow report the
txid of
the open transaction on the primary back to the primary as if it were
running on
the standby?

Is it an unavoidable limitation of the standby feedback mechanism that xmin
is
not tracked by database? It was certainly a surprise to me to find that
hot_standby_feedback can trigger cross-database dependencies like this.

Thanks,
Owen.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Dunstan 2023-05-22 11:52:24 Re: Adding SHOW CREATE TABLE
Previous Message Pavel Stehule 2023-05-22 09:24:21 Re: Adding SHOW CREATE TABLE