On Thu, 17 Nov 2022 at 20:06, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Nov 16, 2022 at 5:14 PM Greg Stark <st...@mit.edu> wrote: > > However I'm not a fan of commands that sometimes do one thing and > > sometimes magically do something very different. I don't like the idea > > that the same vacuum command would sometimes run in-process and > > sometimes do this out of process request. And the rules for when it > > does which are fairly complex to explain -- it runs in process unless > > you're in a transaction when it runs out of process unless it's a > > temporary table ... > > 100% agree.
I agree as well. At the moment, the problem (OT) is that VACUUM behaves inconsistently Outside a transaction - works perfectly In a transaction - throws ERROR, which prevents a whole script from executing correctly What we are trying to do is avoid the ERROR. I don't want them to behave like this, but that's the only option possible to avoid ERROR. So if consistency is also a strong requirement, then maybe we should make that new command the default, i.e. make VACUUM always just a request to vacuum in background. That way it will be consistent. Can we at least have a vacuum_runs_in_background = on | off, to allow users to take advantage of this WITHOUT needing to rewrite all of their scripts? -- Simon Riggs http://www.EnterpriseDB.com/
