From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow single table VACUUM in transaction block |
Date: | 2022-11-07 07:58:13 |
Message-ID: | CANbhV-G5u+vfR5HDtVMd_kiQvTZ_NiL_YKPQ6nToptjkJvhztQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 6 Nov 2022 at 18:50, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Thu, Oct 27, 2022 at 2:31 AM Simon Riggs
> <simon(dot)riggs(at)enterprisedb(dot)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/
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2022-11-07 08:16:32 | Re: Add common function ReplicationOriginName. |
Previous Message | Michael Paquier | 2022-11-07 07:54:07 | Re: Tracking last scan time |