Re: Adding REPACK [concurrently]
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Adding REPACK [concurrently] |
| Дата | |
| Msg-id | aeYvFBkWT0V2_IUZ@alvherre.pgsql обсуждение |
| Ответ на | Re: Adding REPACK [concurrently] (Antonin Houska <ah@cybertec.at>) |
| Ответы |
Re: Adding REPACK [concurrently]
|
| Список | pgsql-hackers |
On 2026-Apr-20, Antonin Houska wrote: > Alvaro Herrera <alvherre@alvh.no-ip.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@kurilemu.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/
В списке pgsql-hackers по дате отправления: