On Sun, 6 Nov 2022 at 18:50, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Thu, Oct 27, 2022 at 2:31 AM Simon Riggs
> <simon.riggs@enterprisedb.com> wrote:
> > Fix, so that this works without issue:
> >
> > BEGIN;
> > ....
> > VACUUM (ANALYZE) vactst;
> > ....
> > COMMIT;
> >
> > Allows both ANALYZE and vacuum of toast tables, but not VACUUM FULL.
> >
> > When in a xact block, we do not set PROC_IN_VACUUM,
> > nor update datfrozenxid.
>
> It doesn't seem like a good idea to add various new special cases to
> VACUUM just to make scripts like this work.
Usability is a major concern that doesn't get a high enough priority.
> I'm pretty sure that there
> are several deep, subtle reasons why VACUUM cannot be assumed safe to
> run in a user transaction.
I expected there were, so it's good to discuss them. Thanks for the input.
> If we absolutely have to do this, then the least worst approach might
> be to make VACUUM into a no-op rather than throwing an ERROR -- demote
> the ERROR into a WARNING. You could argue that we're just arbitrarily
> deciding to not do a VACUUM just to be able to avoid throwing an error
> if we do that. But isn't that already true with the patch that we
> have? Is it really a "true VACUUM" if the operation can never advance
> datfrozenxid? At least selectively demoting the ERROR to a WARNING is
> "transparent" about it.
I'll answer that part in my reply to Tom, since there are good ideas in both.
--
Simon Riggs http://www.EnterpriseDB.com/
