• Tom Lane's avatar
    Fix handling of savepoint commands within multi-statement Query strings. · 6eb52da3
    Tom Lane authored
    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 4f896dac,
    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 4f896dac 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
    6eb52da3
transactions.out 16.9 KB