Re: Allow single table VACUUM in transaction block

From: Rahila Syed <rahilasyed90(at)gmail(dot)com>
To: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allow single table VACUUM in transaction block
Date: 2022-11-04 11:48:08
Message-ID: CAH2L28vDRd2DPxeFuV00HYtu3EF2AKcQeCirCaDVRFiTPaEJHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, Nov 4, 2022 at 2:39 PM Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>
wrote:

> Hi Rahila,
>
> Thanks for your review.
>
> On Fri, 4 Nov 2022 at 07:37, Rahila Syed <rahilasyed90(at)gmail(dot)com> wrote:
>
> >> I would like to bring up a few points that I came across while looking
> into the vacuum code.
> >>
> >> 1. As a result of this change to allow VACUUM inside a user
> transaction, I think there is some chance of causing
> >> a block/delay of concurrent VACUUMs if a VACUUM is being run under a
> long running transaction.
> >> 2. Also, if a user runs VACUUM in a transaction, performance
> optimizations like PROC_IN_VACUUM won't work.
> >> 3. Also, if VACUUM happens towards the end of a long running
> transaction, the snapshot will be old
> >> and xmin horizon for vacuum would be somewhat old as compared to
> current lazy vacuum which
> >> acquires a new snapshot just before scanning the table.
> >>
> >> So, while I understand the need of the feature, I am wondering if there
> should be some mention
> >> of above caveats in documentation with the recommendation that VACUUM
> should be run outside
> >> a transaction, in general.
> >>
> >
> > Sorry, I just noticed that you have already mentioned some of these in
> the documentation as follows, so it seems
> > it is already taken care of.
> >
> > + <command>VACUUM</command> cannot be executed inside a transaction
> block,
> > + unless a single table is specified and <literal>FULL</literal> is
> not
> > + specified. When executing inside a transaction block the vacuum
> scan can
> > + hold back the xmin horizon and does not update the database
> datfrozenxid,
> > + as a result this usage is not useful for database maintenance, but
> is provided
> > + to allow vacuuming in special circumstances, such as temporary or
> private
> > + work tables.
>
> Yes, I wondered whether we should have a NOTICE or WARNING to remind
> people of those points?
>

+1 . My vote for NOTICE over WARNING because I think
it is useful information for the user rather than any potential problem.

Thank you,
Rahila Syed

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-11-04 11:59:01 Re: proposal: possibility to read dumped table's name from file
Previous Message Amit Kapila 2022-11-04 11:44:33 Re: Perform streaming logical transactions by background workers and parallel apply