| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Antonin Houska <ah(at)cybertec(dot)at> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-04-20 13:54:52 |
| Message-ID: | aeYvFBkWT0V2_IUZ@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-Apr-20, Antonin Houska wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > BTW I ran into a small problem after adding some tests in cluster.sql
> > that would exercise this -- that test would die more or less randomly
> > but frequently in CI (which it never did in my laptop) because of the
> > size of the snapshot,
> >
> > ALTER TABLE ptnowner1 REPLICA IDENTITY USING INDEX ptnowner1_i_key;
> > REPACK (CONCURRENTLY) ptnowner1;
> > +ERROR: initial slot snapshot too large
> > +CONTEXT: REPACK decoding worker
> > RESET SESSION AUTHORIZATION;
> >
> > I think the solution for this is to move cluster to a separate parallel
> > test. The one where it is now is a bit too crowded. Maybe the one for
> > compression is okay? I'll test and push if I see it passing CI.
>
> That shouldn't break anything, but I have no idea why this problem was not
> triggered (as far as I remember) by the stress tests we ran during
> development.
I took a guess that it's because some tests use minimally configured
servers -- that is, max_connections=20 or so -- and then run 20
processes. If we then try to construct a snapshot that's limited to
having only that many XIDs, we might not have enough room in the xip
array. I didn't try to trace it super carefully though.
> > >From b3d4158356f4914d2b0cba86eef6994c0ee50ab9 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?=C3=81lvaro=20Herrera?= <alvherre(at)kurilemu(dot)de>
> > Date: Mon, 20 Apr 2026 11:38:48 +0200
> > Subject: [PATCH 1/2] REPACK: do not require the user to have REPLICATION
>
> > Because there are now successful concurrent repack runs in the
> > regression tests, we're forced to run test_plan_advice under
> > wal_level=replica.
>
> Is this an attempt to disable REPACK (CONCURRENTLY)? That would require
> wal_level=minimal (due to commit 67c20979ce). In which way does REPACK seem to
> break test_plan_advice?
No, quite the contrary. That test normally runs with wal_level=minimal,
which causes REPACK to complain that it cannot start logical
decoding.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nisha Moond | 2026-04-20 14:01:41 | Re: Proposal: Conflict log history table for Logical Replication |
| Previous Message | Xuneng Zhou | 2026-04-20 13:54:16 | Re: test: avoid redundant standby catchup in 049_wait_for_lsn |