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.
Cherio <cherio@gmail.com> writes: > I just realized that the ramifications of this change go further than just > VACUUM related statements in the scripts. Assume 2 scripts
> UPDATE tableA > UPDATE tableB
> and
> UPDATE tableA > UPDATE tableB
> Before the change they could run in parallel without issues. After the > change this will cause one of the queries to fail due to transaction locks.
Uh ... really? Please provide evidence. AFAIK this set of changes only affects commands that are meant to not run inside tranaction blocks.
