Horton

Re: Catalog_xmin is not advanced when a logical slot is lost

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: sirisha chamarthi <sirichamarthi22@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, pgsql-hackers@lists.postgresql.org, Amit Kapila <amit.kapila16@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Date: 2022-11-22T10:01:08Z
Lists: pgsql-hackers 
On 2022-Nov-21, sirisha chamarthi wrote:

> On Mon, Nov 21, 2022 at 10:56 AM Alvaro Herrera <alvherre@alvh.no-ip.org>
> wrote:

> > Instead I'm going to do what Ashutosh mentioned at the start, which is
> > to verify both the restart_lsn and the invalidated_at, when deciding
> > whether to ignore the slot.
> 
> Sounds good to me. Thanks!

Done now.  I also a new elog(DEBUG1), which I think makes the issue a
bit easier notice.

I think it would be even better if we reset the underlying data from
effective_catalog_xmin ... even with this patch, we show a non-zero
value for a slot in status "lost" (and we ignore it when computing the
overall xmin), which I think is quite confusing.  But we can do that in
master only.

Thanks for reporting this issue.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

Commits

  1. Ignore invalidated slots while computing oldest catalog Xmin