On 2019-11-08 08:13, Pavel Stehule wrote:
    I dug into repository and found that transformExecuteStmt existed at
    the time of implementing PREPARE-EXECUTE statements(28e82066a1) and
    removed by the commit b9527e9840 which is related to
    plan-invalidation.

    git show -s --format=%B b9527e984092e838790b543b014c0c2720ea4f11
     > In service of this, rearrange utility-statement processing so
    that parse
     > analysis does not assume table schemas can't change before
    execution for
     > utility statements (necessary because we don't attempt to
    re-acquire locks
     > for utility statements when reusing a stored plan).  This
    requires some

    Isn't this related to the current structure?

I think so it should be ok, because the transformation is still in same statement - if I understand well.

So visibility of system catalogue or access to plan cache should not be changed.

I think what that patch was addressing is, if you use a protocol-level prepare+execute with commands like CREATE INDEX, CREATE VIEW, or COPY and you change the table schema between the prepare and execute, things would break, for the reasons explained in the commit message. So any parse analysis in utility statements that accesses table schemas needs to be done in the execute phase, not in the prepare phase, as one might think.

Parse analysis of EXECUTE does not access any tables, so if I understood this correctly, this concern doesn't apply here.

Interestingly, the above commit also removed the prepare-time transformation of ExplainStmt, but it was later put back and now has the comment "We used to postpone that until execution, but it's really necessary to do it during the normal parse analysis phase to ensure that side effects of parser hooks happen at the expected time." So there appears to be a generally uneasy situation still about how to do this correctly.

Perhaps something could be done about the issue "because we don't attempt to re-acquire locks for utility statements when reusing a stored plan"?

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply via email to