Re: BUG #19686: Rolling back SET TABLESPACE

Hi Shihao,

> v6 keeps the shortcut for both protocols. Its cost is that a
> pipelined ALTER commits on its own, but I think few people send
> SET TABLESPACE in a pipeline with other statements.

It does not take an explicit pipeline. I ran an ALTER TABLE SET
TABLESPACE followed by a failing statement, in autocommit mode,
through the batch API of some common drivers. Where the table ends
up, on master, v6 and v7:

pgJDBC 42.7.13, executeBatch(): pg_default, ts, pg_default
pgx 5.11.0, SendBatch(): pg_default, ts, pg_default
psycopg 3.3.6, pipeline(): pg_default, ts, pg_default

On master each batch is one transaction and the failure rolls the
move back. With v6 the move stays, and the application only sees the
error of the later statement. postgres.js, node-postgres and
tokio-postgres send each statement in its own transaction, so they
see no difference.

> v7 changes no behavior, but the shortcut only helps simple protocol
> clients. For me that means mostly psql.

Agreed, the shortcut is narrower. But v7's cost is time only: the
indexes are copied, which made the ALTER at most about 1.7 times
slower in my tests. And the fix is meant for every branch from
REL_14 on, where a minor release should not change what a failed
batch leaves behind.

> I personally prefer v6, but that should be a committer decision.

Agreed. To sum it up for whoever decides: v6 is faster through the
extended protocol and commits the ALTER of a batch on its own; v7
keeps the current behavior and copies the indexes there.

Regards,
Manu