> I think you are working with a completely wrong mental model of what this change did.
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.
From what you are saying I am deriving that transaction model is not affected, and the individual statements still run within their own atomic transactions when AutoCommit is enabled, it's just a limited set of commands (at the moment I am aware of VACUUM and .... ANALYZE???) can't be bundled with any other statements, because doing that blows up the new pipeline :)
BTW, why ANALYZE? I just tested ANALYZE and it seems to work without the need to be preceded with COMMIT.
Are VACUUM and ANALYZE the only commands that must be executed separately?
Again, is there at least a brief description of the scope of what was affected?
I believe I understand it better now but the picture is still made of bits and pieces glued with trial and error.
Cherio <cherio@gmail.com> writes:
> The second script should have tables used in the reversed order:
> UPDATE tableA
> UPDATE tableB
> and
> UPDATE tableB
> UPDATE tableA
> Since they will run in individual transactions tableA gets locked by the
> 1st script and tableB by the 2nd; as execution flow proceeds to the next
> update in each script, those tables would be locked in separate
> transactions.
I think you are working with a completely wrong mental model of what
this change did. It will not affect a pipeline that doesn't contain
any VACUUM, ANALYZE, or similar maintenance commands.
regards, tom lane