Re: Adding REPACK [concurrently]

From: Antonin Houska <ah(at)cybertec(dot)at>
To: Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>
Cc: alvherre(at)alvh(dot)no-ip(dot)org, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2026-03-06 07:14:55
Message-ID: 4200.1772781295@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Antonin Houska <ah(at)cybertec(dot)at> wrote:

> Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com> wrote:
>
> > The concurrency test failed once. I tried to reproduce the below scenario
> > but no luck,i think the reason the assert failure happened because
> > after speculative insert there might be no spec CONFIRM or ABORT, thoughts?
>
> Perhaps, I'll try. I'm not sure the REPACK decoding worker does anthing
> special regarding decoding. If you happen to see the problem again, please try
> to preserve the related WAL segments - if this is a bug in PG executor,
> pg_waldump might reveal that.

I could not reproduce the failure, and have no idea how speculative insert can
stay w/o CONFIRM / ABORT record. The only problem I could imagine is that
change_useless_for_repack() filters out the CONFIRM / ABORT record
accidentally, but neither code review nor debugger proves that
theory. (Actually if this was the problem, the test failure probably wouldn't
be that rare.)

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Madyshev Egor 2026-03-06 07:26:44 RE: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)
Previous Message Shinya Kato 2026-03-06 07:12:48 Re: pg_stat_replication.*_lag sometimes shows NULL during active replication