Re: A concurrent VACUUM FULL? - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: A concurrent VACUUM FULL?
Date
Msg-id 26037.1751285018@localhost
Whole thread Raw
In response to Re: A concurrent VACUUM FULL?  (Erik Nordström <erik@timescale.com>)
Responses Re: A concurrent VACUUM FULL?
List pgsql-hackers
Erik Nordström <erik@timescale.com> wrote:

> On Mon, Jun 30, 2025 at 1:46 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
>  On 2025-Jun-30, Erik Nordström wrote:
>
>  > On Mon, Jun 30, 2025 at 12:03 PM Antonin Houska <ah@cybertec.at> wrote:
>
>  > > Patch [1] is in the queue that allows both reads and writes. (An exclusive
>  > > lock is acquired here for the swaps, but that should be held for very short
>  > > time.)
>  >
>  > That sounds great. Do you know if there's anything I can do to help?
>
>  It would be very valuable if you can review the code, test it under the
>  weirdest conditions you can imagine or just under normal conditions,
>  proof-read the documentation, try to see if anything is missing that
>  should be there, and so on.  Everything that you would expect from a new
>  feature released as part of the next Postgres release.  Any
>  problems/crashes/ abnormalities that you report before the patch is
>  included in Postgres, is one less issue that we'll have to deal with
>  after the release.
>
> I'll do my best to test the feature.

Thanks. I've noticed that the patch set needs rebase. I'll try to prepare a
new version today.

> One question I have, though, is why not start with supporting concurrent reads but not writes? That would
> already be a win and make the patch simpler.

It occurred to me at some point too, but I think it would be rather a
different implementation. So if we were to support both read-only and
read-write modes, the amount of code would be even higher.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com



pgsql-hackers by date:

Previous
From: Jakub Wartak
Date:
Subject: Re: NUMA shared memory interleaving
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: pg_logical_slot_get_changes waits continously for a partial WAL record spanning across 2 pages