From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: hot_standby_feedback implementation |
Date: | 2021-06-16 00:41:36 |
Message-ID: | CD8D4757-ECC0-4CBA-9E26-A07617670249@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On Jun 15, 2021, at 17:30, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> It pretty much works by making the WAL sender process on the primary
> look like it holds a snapshot that's as old as the oldest snapshot on
> the replica.
>
> A replica can block VACUUM on the primary *directly* by holding a
> table-level lock, though in practice only when somebody on the replica
> acquires an AccessExclusiveLock -- which is presumably rare in
> practice.
Thank you! Attempting to track down a sudden burst of every session waiting on lock_manager LW locks, and part of that is finding the source of locks.
From | Date | Subject | |
---|---|---|---|
Next Message | Dipanjan Das | 2021-06-16 04:53:45 | pg_basebackup fails with "COPY stream ended" |
Previous Message | Peter Geoghegan | 2021-06-16 00:30:52 | Re: hot_standby_feedback implementation |