Alvaro Herrera <[email protected]> wrote: > On 2026-Apr-20, Antonin Houska wrote: > > > Antonin Houska <[email protected]> wrote: > > > > > It was discussed earlier [1] and the concerns about possibly excessive > > > resource consumptions were addressed by [2]. So I think it the fix was > > > just > > > forgotten. Attached here. > > > > Sorry, I attached wrong patch. This is what I meant. > > Yeah, I had also written the same patch a couple of days ago. > > 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 thought that it might be due to less frequent calls of SnapBuildPurgeOlderTxn(), which might in turn be due to less frequent checkpoints (because xl_running_xacts is typically written during checkpoint), and that checkpoints may be deliberately less frequent to make regression tests run faster. However I don't immediately see related configuration in the regression test setup. > Another obvious thing after adding tests is that the LOGIN privilege is > required, which is also quite bogus IMO. 0002 here should solve that. ok > >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? -- Antonin Houska Web: https://www.cybertec-postgresql.com
