Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM

Cherio <cherio(at)gmail(dot)com> writes:
> You are right. My mental model of the change is a speculation, but this is
> only because the specifics of the change are not clarified anywhere.

The problem is that statements that aren't allowed to execute in a
transaction block (usually because they need an immediate commit)
weren't checking that properly in the context of pipelined queries.
This should never have been allowed, but we weren't enforcing that
properly. The net effect in some cases is that such commands
unexpectedly committed the effects of prior commands in the pipeline,
and in other cases that a rollback occurring later in the pipeline
would leave you with corrupted on-disk state. We judged that to be
a bad enough bug that the fix should be backpatched.

The original fix for that went in six months ago (13.8 et al) but
we later discovered that there was still a hole in it. The fact
that the 13.10 release notes only mention ANALYZE is a result of
my inadequate summarization of the commit log entry :-(.

> BTW, why ANALYZE?

ANALYZE is a slightly different case. It can work inside a transaction
block or not, but it has two different strategies depending on that: one
uses internal commits and the other doesn't. It was applying the wrong
one in this context, which again had the effect of prematurely committing
previous commands in the pipeline.

> Are VACUUM and ANALYZE the only commands that must be executed
> separately?

There's a couple dozen such commands --- easiest way to find them
is to grep the source code for PreventInTransactionBlock calls.
I believe "can't run inside a transaction block" is mentioned in
all their manual pages, but we don't have a central list.

regards, tom lane