rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-08-23 11:20:40 +02:00
Code Issues Packages Projects Releases Wiki Activity
6eb52da394
postgresql/src/test/regress
History
Tom Lane 6eb52da394 Fix handling of savepoint commands within multi-statement Query strings. 
Issuing a savepoint-related command in a Query message that contains
multiple SQL statements led to a FATAL exit with a complaint about
"unexpected state STARTED".  This is a shortcoming of commit 4f896dac1,
which attempted to prevent such misbehaviors in multi-statement strings;
its quick hack of marking the individual statements as "not top-level"
does the wrong thing in this case, and isn't a very accurate description
of the situation anyway.

To fix, let's introduce into xact.c an explicit model of what happens for
multi-statement Query strings.  This is an "implicit transaction block
in progress" state, which for many purposes works like the normal
TBLOCK_INPROGRESS state --- in particular, IsTransactionBlock returns true,
causing the desired result that PreventTransactionChain will throw error.
But in case of error abort it works like TBLOCK_STARTED, allowing the
transaction to be cancelled without need for an explicit ROLLBACK command.

Commit 4f896dac1 is reverted in toto, so that we go back to treating the
individual statements as "top level".  We could have left it as-is, but
this allows sharpening the error message for PreventTransactionChain
calls inside functions.

Except for getting a normal error instead of a FATAL exit for savepoint
commands, this patch should result in no user-visible behavioral change
(other than that one error message rewording).  There are some things
we might want to do in the line of changing the appearance or wording of
error and warning messages around this behavior, which would be much
simpler to do now that it's an explicitly modeled state.  But I haven't
done them here.

Although this fixes a long-standing bug, no backpatch.  The consequences
of the bug don't seem severe enough to justify the risk that this commit
itself creates some new issue.

Patch by me, but it owes something to previous investigation by
Takayuki Tsunakawa, who also reported the bug in the first place.
Also thanks to Michael Paquier for reviewing.

Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F6BE40D@G01JPEXMBYT05
2017-09-07 09:49:55 -04:00
..
data Improve key representation for GIN jsonb_ops, and fix existence-search bug. 2014-05-09 08:41:26 -04:00
expected Fix handling of savepoint commands within multi-statement Query strings. 2017-09-07 09:49:55 -04:00
input Merge large_object.sql test into largeobject.source. 2017-07-17 15:28:20 -04:00
output Merge large_object.sql test into largeobject.source. 2017-07-17 15:28:20 -04:00
sql Fix handling of savepoint commands within multi-statement Query strings. 2017-09-07 09:49:55 -04:00
.gitignore Update .gitignore for config.cache. 2014-12-18 19:56:42 +09:00
GNUmakefile Remove ICU tests from default run 2017-03-25 00:30:26 -04:00
Makefile Remove remains of old depend target. 2007-01-20 17:16:17 +00:00
parallel_schedule Introduce 64-bit hash functions with a 64-bit seed. 2017-08-31 22:21:21 -04:00
pg_regress_main.c Fix inclusions of postgres_fe.h from .h files. 2017-03-08 20:41:06 -05:00
pg_regress.c Phase 3 of pgindent updates. 2017-06-21 15:35:54 -04:00
pg_regress.h Initial pgindent run with pg_bsd_indent version 2.0. 2017-06-21 14:39:04 -04:00
README Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:04 -05:00
regress.c Remove to pre-8.2 coding convention for PG_MODULE_MAGIC 2017-08-30 22:40:24 -04:00
regressplans.sh Rename 'gmake' to 'make' in docs and recommended commands 2014-02-12 17:29:19 -05:00
resultmap Enable compiling with the mingw-w64 32 bit compiler. 2011-12-10 15:35:41 -05:00
serial_schedule Merge large_object.sql test into largeobject.source. 2017-07-17 15:28:20 -04:00
standby_schedule Remove cvs keywords from all files. 2010-09-20 22:08:53 +02:00

README 

Documentation concerning how to run these regression tests and interpret
the results can be found in the PostgreSQL manual, in the chapter
"Regression Tests".