Re: A concurrent VACUUM FULL?

HI Erik Nordström
In online production environments, blocking writes is generally
unacceptable in most cases. The only acceptable approach is to allow
concurrent read/write operations, with brief locks permitted only during
the final steps of the process. We can see pg-osc's implementation (
https://github.com/shayonj/pg-osc) for a non-blocking approach to VACUUM
FULL operations."

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
无病毒。www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Jun 30, 2025 at 8:03 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:

> Erik Nordström <erik(at)timescale(dot)com> wrote:
>
> > On Mon, Jun 30, 2025 at 1:46 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de>
> wrote:
> >
> > On 2025-Jun-30, Erik Nordström wrote:
> >
> > > On Mon, Jun 30, 2025 at 12:03 PM Antonin Houska <ah(at)cybertec(dot)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
>
>
>