public inbox for [email protected]  

help / color / mirror / Atom feed

From: Alvaro Herrera <[email protected]>
To: Antonin Houska <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Mihail Nikalayeu <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: [email protected]
Cc: Robert Treat <[email protected]>
Subject: Re: Adding REPACK [concurrently]
Date: Mon, 20 Apr 2026 15:54:52 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <62070.1776692773@localhost>

On 2026-Apr-20, Antonin Houska wrote:

> Alvaro Herrera <[email protected]> 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?= <[email protected]>
> > 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/

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Adding REPACK [concurrently]
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox