Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: Adding REPACK [concurrently]
Date
Msg-id 4200.1772781295@localhost
Whole thread Raw
In response to Re: Adding REPACK [concurrently]  (Antonin Houska <ah@cybertec.at>)
List pgsql-hackers
Antonin Houska <ah@cybertec.at> wrote:

> Srinath Reddy Sadipiralla <srinath2133@gmail.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



pgsql-hackers by date:

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