1. 22 Nov, 2021 3 commits
  2. 21 Nov, 2021 1 commit
    • Tom Lane's avatar
      pg_receivewal, pg_recvlogical: allow canceling initial password prompt. · 3bd7556b
      Tom Lane authored
      Previously it was impossible to terminate these programs via control-C
      while they were prompting for a password.  We can fix that trivially
      for their initial password prompts, by moving setup of the SIGINT
      handler from just before to just after their initial GetConnection()
      calls.
      
      This fix doesn't permit escaping out of later re-prompts, but those
      should be exceedingly rare, since the user's password or the server's
      authentication setup would have to have changed meanwhile.  We
      considered applying a fix similar to commit 46d665bc2, but that
      seemed more complicated than it'd be worth.  Moreover, this way is
      back-patchable, which that wasn't.
      
      The misbehavior exists in all supported versions, so back-patch to all.
      
      Tom Lane and Nathan Bossart
      
      Discussion: https://postgr.es/m/747443.1635536754@sss.pgh.pa.us
      3bd7556b
  3. 20 Nov, 2021 1 commit
    • Tom Lane's avatar
      Fix SP-GiST scan initialization logic for binary-compatible cases. · 6d07cbc5
      Tom Lane authored
      Commit ac9099fc rearranged the logic in spgGetCache() that determines
      the index's attType (nominal input data type) and leafType (actual
      type stored in leaf index tuples).  Turns out this broke things for
      the case where (a) the actual input data type is different from the
      nominal type, (b) the opclass's config function leaves leafType
      defaulted, and (c) the opclass has no "compress" function.  (b) caused
      us to assign the actual input data type as leafType, and then since
      that's not attType, we complained that a "compress" function is
      required.  For non-polymorphic opclasses, condition (a) arises in
      binary-compatible cases, such as using SP-GiST text_ops for a varchar
      column, or using any opclass on a domain over its nominal input type.
      
      To fix, use attType for leafType when the index's declared column type
      is different from but binary-compatible with attType.  Do this only in
      the defaulted-leafType case, to avoid overriding any explicit
      selection made by the opclass.
      
      Per bug #17294 from Ilya Anfimov.  Back-patch to v14.
      
      Discussion: https://postgr.es/m/17294-8f6c7962ce877edc@postgresql.org
      6d07cbc5
  4. 19 Nov, 2021 1 commit
    • Amit Kapila's avatar
      Fix parallel operations that prevent oldest xmin from advancing. · ead49ebc
      Amit Kapila authored
      While determining xid horizons, we skip over backends that are running
      Vacuum. We also ignore Create Index Concurrently, or Reindex Concurrently
      for the purposes of computing Xmin for Vacuum. But we were not setting the
      flags corresponding to these operations when they are performed in
      parallel which was preventing Xid horizon from advancing.
      
      The optimization related to skipping Create Index Concurrently, or Reindex
      Concurrently operations was implemented in PG-14 but the fix is the same
      for the Parallel Vacuum as well so back-patched till PG-13.
      
      Author: Masahiko Sawada
      Reviewed-by: Amit Kapila
      Backpatch-through: 13
      Discussion: https://postgr.es/m/CAD21AoCLQqgM1sXh9BrDFq0uzd3RBFKi=Vfo6cjjKODm0Onr5w@mail.gmail.com
      ead49ebc
  5. 18 Nov, 2021 3 commits
    • Tom Lane's avatar
      Use appropriate -Wno-warning switches when compiling bitcode. · ed1c261a
      Tom Lane authored
      We use "clang" to compile bitcode files for LLVM inlining.  That might
      be different from the build's main C compiler, so it needs its own set
      of compiler flags.  To simplify configure, we don't bother adding any
      -W switches to that flag set; there's little need since the main build
      will show us any warnings.  However, if we don't want to see unwanted
      warnings, we still have to add any -Wno-warning switches we'd normally
      use with clang.
      
      This escaped notice before commit 9ff47ea41, which tried to add
      -Wno-compound-token-split-by-macro; buildfarm animals using mismatched
      CC and CLANG still showed those warnings.  I'm not sure why we never
      saw any effects from the lack of -Wno-unused-command-line-argument
      (maybe that's only activated by -Wall?).  clang does not currently
      support -Wno-format-truncation or -Wno-stringop-truncation, although
      in the interests of future-proofing and consistency I included tests
      for those.
      
      Back-patch to v11 where we started building bitcode files.
      
      Discussion: https://postgr.es/m/2921539.1637254619@sss.pgh.pa.us
      ed1c261a
    • Michael Paquier's avatar
      Fix quoting of ACL item in table for upgrade binary compatibility checks · 048f3ee6
      Michael Paquier authored
      Per buildfarm member prion, that runs the regression tests under a role
      name that uses a hyphen.  Issue introduced by 835bcba.
      
      Discussion: https://postgr.es/m/YZW4MvzCZ+hQ34vw@paquier.xyz
      Backpatch-through: 12
      048f3ee6
    • Michael Paquier's avatar
      Add table to regression tests for binary-compatibility checks in pg_upgrade · cf3d79aa
      Michael Paquier authored
      This commit adds to the main regression test suite a table with all
      the in-core data types (some exceptions apply).  This table is not
      dropped, so as pg_upgrade would be able to check the binary
      compatibility of the types tracked in the table.  If a new type is added
      in core, this part of the tests would need a refresh but the tests are
      designed to fail if that were to happen.
      
      As this is useful for upgrades and that these rely on the objects
      created in the regression test suite of the old version upgraded from,
      a backpatch down to 12 is done, which is the last point where a binary
      incompatible change has been done (7c15cef8).  This will hopefully be
      enough to find out if something gets broken during the development of a
      new version of Postgres, so as it is possible to take actions in
      pg_upgrade itself in this case (like 0ccfc282 for sql_identifier).
      
      An area that is not covered yet is related to external modules, which
      may create their own types.  The testing infrastructure of pg_upgrade is
      not integrated yet with the external modules stored in core
      (src/test/modules/ or contrib/, all use the same database name for their
      tests so there would be an overlap).  This could be improved in the
      future.
      
      Author: Justin Pryzby
      Reviewed-by: Jacob Champion, Peter Eisentraut, Tom Lane, Michael Paquier
      Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com
      Backpatch-through: 12
      cf3d79aa
  6. 17 Nov, 2021 4 commits
    • Tom Lane's avatar
      Clean up error handling in pg_basebackup's walmethods.c. · 53c4a580
      Tom Lane authored
      The error handling here was a mess, as a result of a fundamentally
      bad design (relying on errno to keep its value much longer than is
      safe to assume) as well as a lot of just plain sloppiness, both as
      to noticing errors at all and as to reporting the correct errno.
      Moreover, the recent addition of LZ4 compression broke things
      completely, because liblz4 doesn't use errno to report errors.
      
      To improve matters, keep the error state in the DirectoryMethodData or
      TarMethodData struct, and add a string field so we can handle cases
      that don't set errno.  (The tar methods already had a version of this,
      but it can be done more efficiently since all these cases use a
      constant error string.)  Make the dir and tar methods handle errors
      in basically identical ways, which they didn't before.
      
      This requires copying errno into the state struct in a lot of places,
      which is a bit tedious, but it has the virtue that we can get rid of
      ad-hoc code to save and restore errno in a number of places ... not
      to mention that it fixes other places that should've saved/restored
      errno but neglected to.
      
      In passing, fix some pointlessly static buffers to be ordinary
      local variables.
      
      There remains an issue about exactly how to handle errors from
      fsync(), but that seems like material for its own patch.
      
      While the LZ4 problems are new, all the rest of this is fixes for
      old bugs, so backpatch to v10 where walmethods.c was introduced.
      
      Patch by me; thanks to Michael Paquier for review.
      
      Discussion: https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us
      53c4a580
    • Tom Lane's avatar
      Handle close() failures more robustly in pg_dump and pg_basebackup. · 6b413b41
      Tom Lane authored
      Coverity complained that applying get_gz_error after a failed gzclose,
      as we did in one place in pg_basebackup, is unsafe.  I think it's
      right: it's entirely likely that the call is touching freed memory.
      Change that to inspect errno, as we do for other gzclose calls.
      
      Also, be careful to initialize errno to zero immediately before any
      gzclose() call where we care about the error status.  (There are
      some calls where we don't, because we already failed at some previous
      step.)  This ensures that we don't get a misleadingly irrelevant
      error code if gzclose() fails in a way that doesn't set errno.
      We could work harder at that, but it looks to me like all such cases
      are basically can't-happen if we're not misusing zlib, so it's
      not worth the extra notational cruft that would be required.
      
      Also, fix several places that simply failed to check for close-time
      errors at all, mostly at some remove from the close or gzclose itself;
      and one place that did check but didn't bother to report the errno.
      
      Back-patch to v12.  These mistakes are older than that, but between
      the frontend logging API changes that happened in v12 and the fact
      that frontend code can't rely on %m before that, the patch would need
      substantial revision to work in older branches.  It doesn't quite
      seem worth the trouble given the lack of related field complaints.
      
      Patch by me; thanks to Michael Paquier for review.
      
      Discussion: https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us
      6b413b41
    • Tom Lane's avatar
      Fix display of SQL-standard function's arguments in INSERT/SELECT. · 5d5779ae
      Tom Lane authored
      If a SQL-standard function body contains an INSERT ... SELECT statement,
      any function parameters referenced within the SELECT were always printed
      in $N style, rather than using the parameter name if any.  While not
      strictly incorrect, this wasn't the intention, and it's inconsistent
      with the way that such parameters would be printed in any other kind
      of statement.
      
      The cause is that the recursion to get_query_def from
      get_insert_query_def neglected to pass down the context->namespaces
      list, passing constant NIL instead.  This is a very ancient oversight,
      but AFAICT it had no visible consequences before commit e717a9a1
      added an outermost namespace with function parameters.  We don't allow
      INSERT ... SELECT as a sub-query, except in a top-level WITH clause,
      where it couldn't contain any outer references that might need to access
      upper namespaces.  So although that's arguably a bug, I don't see any
      point in changing it before v14.
      
      In passing, harden the code added to get_parameter by e717a9a1 so that
      it won't crash if a PARAM_EXTERN Param appears in an unexpected place.
      
      Per report from Erki Eessaar.  Code fix by me, regression test case
      by Masahiko Sawada.
      
      Discussion: https://postgr.es/m/AM9PR01MB8268347BED344848555167FAFE949@AM9PR01MB8268.eurprd01.prod.exchangelabs.com
      5d5779ae
    • Daniel Gustafsson's avatar
      Doc: add see-also references to CREATE PUBLICATION. · 51d42136
      Daniel Gustafsson authored
      The "See also" section on the reference page for CREATE PUBLICATION
      didn't match the cross references on CREATE SUBSCRIPTION and their
      ALTER counterparts. Fixed by adding an xref to the CREATE and ALTER
      SUBSCRIPTION pages.  Backpatch down to v10 where CREATE PUBLICATION
      was introduced.
      
      Author: Peter Smith <smithpb2250@gmail.com>
      Reviewed-by: default avatarMasahiko Sawada <sawada.mshk@gmail.com>
      Discussion: https://postgr.es/m/CAHut+PvGWd3-Ktn96c-z6uq-8TGVVP=TPOkEovkEfntoo2mRhw@mail.gmail.com
      Backpatch-through: 10
      51d42136
  7. 16 Nov, 2021 1 commit
  8. 12 Nov, 2021 3 commits
    • Tom Lane's avatar
      Make psql's \password default to CURRENT_USER, not PQuser(conn). · 99389cb6
      Tom Lane authored
      The documentation says plainly that \password acts on "the current user"
      by default.  What it actually acted on, or tried to, was the username
      used to log into the current session.  This is not the same thing if
      one has since done SET ROLE or SET SESSION AUTHENTICATION.  Aside from
      the possible surprise factor, it's quite likely that the current role
      doesn't have permissions to set the password of the original role.
      
      To fix, use "SELECT CURRENT_USER" to get the role name to act on.
      (This syntax works with servers at least back to 7.0.)  Also, in
      hopes of reducing confusion, include the role name that will be
      acted on in the password prompt.
      
      The discrepancy from the documentation makes this a bug, so
      back-patch to all supported branches.
      
      Patch by me; thanks to Nathan Bossart for review.
      
      Discussion: https://postgr.es/m/747443.1635536754@sss.pgh.pa.us
      99389cb6
    • Michael Paquier's avatar
      Fix memory overrun when querying pg_stat_slru · 5f81a480
      Michael Paquier authored
      pg_stat_get_slru() in pgstatfuncs.c would point to one element after the
      end of the array PgStat_SLRUStats when finishing to scan its entries.
      This had no direct consequences as no data from the extra memory area
      was read, but static analyzers would rightfully complain here.  So let's
      be clean.
      
      While on it, this adds one regression test in the area reserved for
      system views.
      
      Reported-by: Alexander Kozhemyakin, via AddressSanitizer
      Author: Kyotaro Horiguchi
      Discussion: https://postgr.es/m/17280-37da556e86032070@postgresql.org
      Backpatch-through: 13
      5f81a480
    • Noah Misch's avatar
      Report any XLogReadRecord() error in XlogReadTwoPhaseData(). · 675cd765
      Noah Misch authored
      Buildfarm members kittiwake and tadarida have witnessed errors at this
      site.  The site discarded key facts.  Back-patch to v10 (all supported
      versions).
      
      Reviewed by Michael Paquier and Tom Lane.
      
      Discussion: https://postgr.es/m/20211107013157.GB790288@rfd.leadboat.com
      675cd765
  9. 11 Nov, 2021 3 commits
    • Alvaro Herrera's avatar
      Restore lock level to set vacuum flags · 9aa91cb3
      Alvaro Herrera authored
      Commit 27838981 mistakenly reduced the lock level from exclusive to
      shared that is acquired to set PGPROC->statusFlags; this was reverted
      by dcfff74f, but failed to do so in one spot.  Fix it.
      
      Backpatch to 14.
      
      Noted by Andres Freund.
      
      Discussion: https://postgr.es/m/20211111020724.ggsfhcq3krq5r4hb@alap3.anarazel.de
      9aa91cb3
    • Michael Paquier's avatar
      Fix buffer overrun in unicode string normalization with empty input · b609db71
      Michael Paquier authored
      PostgreSQL 13 and newer versions are directly impacted by that through
      the SQL function normalize(), which would cause a call of this function
      to write one byte past its allocation if using in input an empty
      string after recomposing the string with NFC and NFKC.  Older versions
      (v10~v12) are not directly affected by this problem as the only code
      path using normalization is SASLprep in SCRAM authentication that
      forbids the case of an empty string, but let's make the code more robust
      anyway there so as any out-of-core callers of this function are covered.
      
      The solution chosen to fix this issue is simple, with the addition of a
      fast-exit path if the decomposed string is found as empty.  This would
      only happen for an empty string as at its lowest level a codepoint would
      be decomposed as itself if it has no entry in the decomposition table or
      if it has a decomposition size of 0.
      
      Some tests are added to cover this issue in v13~.  Note that an empty
      string has always been considered as normalized (grammar "IS NF[K]{C,D}
      NORMALIZED", through the SQL function is_normalized()) for all the
      operations allowed (NFC, NFD, NFKC and NFKD) since this feature has been
      introduced as of 2991ac5f.  This behavior is unchanged but some tests are
      added in v13~ to check after that.
      
      I have also checked "make normalization-check" in src/common/unicode/,
      while on it (works in 13~, and breaks in older stable branches
      independently of this commit).
      
      The release notes should just mention this commit for v13~.
      
      Reported-by: Matthijs van der Vleuten
      Discussion: https://postgr.es/m/17277-0c527a373794e802@postgresql.org
      Backpatch-through: 10
      b609db71
    • Michael Paquier's avatar
      Clean up compilation warnings coming from PL/Perl with clang-12~ · 56eb02ce
      Michael Paquier authored
      clang-12 has introduced -Wcompound-token-split-by-macro, that is causing
      a large amount of warnings when building PL/Perl because of its
      interactions with upstream Perl.  This commit adds one -Wno to CFLAGS at
      ./configure time if the flag is supported by the compiler to silence all
      those warnings.
      
      Upstream perl has fixed this issue, but it is going to take some time
      before this is spread across the buildfarm, and we have noticed that
      some animals would be useful with an extra -Werror to help with the
      detection of incorrect placeholders (see b0cf544), dangomushi being
      one.
      
      Reviewed-by: Tom Lane
      Discussion: https://postgr.es/m/YYr3qYa/R3Gw+Sbg@paquier.xyz
      Backpatch-through: 10
      56eb02ce
  10. 10 Nov, 2021 1 commit
  11. 09 Nov, 2021 1 commit
  12. 08 Nov, 2021 6 commits
    • Tom Lane's avatar
      Stamp 14.1. · 0a455b8d
      Tom Lane authored
      0a455b8d
    • Tom Lane's avatar
      Last-minute updates for release notes. · ddc6917c
      Tom Lane authored
      Security: CVE-2021-23214, CVE-2021-23222
      ddc6917c
    • Tom Lane's avatar
      libpq: reject extraneous data after SSL or GSS encryption handshake. · 30547d79
      Tom Lane authored
      libpq collects up to a bufferload of data whenever it reads data from
      the socket.  When SSL or GSS encryption is requested during startup,
      any additional data received with the server's yes-or-no reply
      remained in the buffer, and would be treated as already-decrypted data
      once the encryption handshake completed.  Thus, a man-in-the-middle
      with the ability to inject data into the TCP connection could stuff
      some cleartext data into the start of a supposedly encryption-protected
      database session.
      
      This could probably be abused to inject faked responses to the
      client's first few queries, although other details of libpq's behavior
      make that harder than it sounds.  A different line of attack is to
      exfiltrate the client's password, or other sensitive data that might
      be sent early in the session.  That has been shown to be possible with
      a server vulnerable to CVE-2021-23214.
      
      To fix, throw a protocol-violation error if the internal buffer
      is not empty after the encryption handshake.
      
      Our thanks to Jacob Champion for reporting this problem.
      
      Security: CVE-2021-23222
      30547d79
    • Tom Lane's avatar
      Reject extraneous data after SSL or GSS encryption handshake. · 9d5a76b8
      Tom Lane authored
      The server collects up to a bufferload of data whenever it reads data
      from the client socket.  When SSL or GSS encryption is requested
      during startup, any additional data received with the initial
      request message remained in the buffer, and would be treated as
      already-decrypted data once the encryption handshake completed.
      Thus, a man-in-the-middle with the ability to inject data into the
      TCP connection could stuff some cleartext data into the start of
      a supposedly encryption-protected database session.
      
      This could be abused to send faked SQL commands to the server,
      although that would only work if the server did not demand any
      authentication data.  (However, a server relying on SSL certificate
      authentication might well not do so.)
      
      To fix, throw a protocol-violation error if the internal buffer
      is not empty after the encryption handshake.
      
      Our thanks to Jacob Champion for reporting this problem.
      
      Security: CVE-2021-23214
      9d5a76b8
    • Peter Eisentraut's avatar
      Translation updates · 5a756120
      Peter Eisentraut authored
      Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
      Source-Git-Hash: f54c1d7c2c97bb2a238a149e407023a9bc007b06
      5a756120
    • David Rowley's avatar
      Fix incorrect hash equality operator bug in Memoize · 1f194ed6
      David Rowley authored
      In v14, because we don't have a field in RestrictInfo to cache both the
      left and right type's hash equality operator, we just restrict the scope
      of Memoize to only when the left and right types of a RestrictInfo are the
      same.
      
      In master we add another field to RestrictInfo and cache both hash
      equality operators.
      
      Reported-by: Jaime Casanova
      Author: David Rowley
      Discussion: https://postgr.es/m/20210929185544.GB24346%40ahch-to
      Backpatch-through: 14
      1f194ed6
  13. 07 Nov, 2021 1 commit
  14. 06 Nov, 2021 4 commits
    • Alexander Korotkov's avatar
      Reset lastOverflowedXid on standby when needed · b0f6bd48
      Alexander Korotkov authored
      Currently, lastOverflowedXid is never reset.  It's just adjusted on new
      transactions known to be overflowed.  But if there are no overflowed
      transactions for a long time, snapshots could be mistakenly marked as
      suboverflowed due to wraparound.
      
      This commit fixes this issue by resetting lastOverflowedXid when needed
      altogether with KnownAssignedXids.
      
      Backpatch to all supported versions.
      
      Reported-by: Stan Hu
      Discussion: https://postgr.es/m/CAMBWrQ%3DFp5UAsU_nATY7EMY7NHczG4-DTDU%3DmCvBQZAQ6wa2xQ%40mail.gmail.com
      Author: Kyotaro Horiguchi, Alexander Korotkov
      Reviewed-by: Stan Hu, Simon Riggs, Nikolay Samokhvalov, Andrey Borodin, Dmitry Dolgov
      b0f6bd48
    • Tom Lane's avatar
      Second-draft release notes for 14.1. · 01a11c77
      Tom Lane authored
      Add latest commits.  Fix some typos and infelicitous wording
      (thanks to Justin Pryzby for proof-reading).
      01a11c77
    • Tomas Vondra's avatar
      Fix handling of NaN values in BRIN minmax multi · f7829feb
      Tomas Vondra authored
      When calculating distance between float4/float8 values, we need to be a
      bit more careful about NaN values in order not to trigger assert. We
      consider NaN values to be equal (distace 0.0) and in infinite distance
      from all other values.
      
      On builds without asserts, this issue is mostly harmless - the ranges
      may be merged in less efficient order, but the index is still correct.
      
      Per report from Andreas Seltenreich. Backpatch to 14, where this new
      BRIN opclass was introduced.
      
      Reported-by: Andreas Seltenreich
      Discussion: https://postgr.es/m/87r1bw9ukm.fsf@credativ.de
      f7829feb
    • Tom Lane's avatar
      First-draft release notes for 14.1. · 39387228
      Tom Lane authored
      As usual, the release notes for other branches will be made by cutting
      these down, but put them up for community review first.
      
      Also as usual for a .1 release, there are some entries here that
      are not really relevant for v14 because they already appeared in 14.0.
      Those'll be removed later.
      39387228
  15. 05 Nov, 2021 2 commits
  16. 03 Nov, 2021 3 commits
  17. 02 Nov, 2021 2 commits
    • Peter Geoghegan's avatar
      Don't overlook indexes during parallel VACUUM. · 61a86ed5
      Peter Geoghegan authored
      Commit b4af70cb, which simplified state managed by VACUUM, performed
      refactoring of parallel VACUUM in passing.  Confusion about the exact
      details of the tasks that the leader process is responsible for led to
      code that made it possible for parallel VACUUM to miss a subset of the
      table's indexes entirely.  Specifically, indexes that fell under the
      min_parallel_index_scan_size size cutoff were missed.  These indexes are
      supposed to be vacuumed by the leader (alongside any parallel unsafe
      indexes), but weren't vacuumed at all.  Affected indexes could easily
      end up with duplicate heap TIDs, once heap TIDs were recycled for new
      heap tuples.  This had generic symptoms that might be seen with almost
      any index corruption involving structural inconsistencies between an
      index and its table.
      
      To fix, make sure that the parallel VACUUM leader process performs any
      required index vacuuming for indexes that happen to be below the size
      cutoff.  Also document the design of parallel VACUUM with these
      below-size-cutoff indexes.
      
      It's unclear how many users might be affected by this bug.  There had to
      be at least three indexes on the table to hit the bug: a smaller index,
      plus at least two additional indexes that themselves exceed the size
      cutoff.  Cases with just one additional index would not run into
      trouble, since the parallel VACUUM cost model requires two
      larger-than-cutoff indexes on the table to apply any parallel
      processing.  Note also that autovacuum was not affected, since it never
      uses parallel processing.
      
      Test case based on tests from a larger patch to test parallel VACUUM by
      Masahiko Sawada.
      
      Many thanks to Kamigishi Rei for her invaluable help with tracking this
      problem down.
      
      Author: Peter Geoghegan <pg@bowt.ie>
      Author: Masahiko Sawada <sawada.mshk@gmail.com>
      Reported-By: default avatarKamigishi Rei <iijima.yun@koumakan.jp>
      Reported-By: default avatarAndrew Gierth <andrew@tao11.riddles.org.uk>
      Diagnosed-By: default avatarAndres Freund <andres@anarazel.de>
      Bug: #17245
      Discussion: https://postgr.es/m/17245-ddf06aaf85735f36@postgresql.org
      Discussion: https://postgr.es/m/20211030023740.qbnsl2xaoh2grq3d@alap3.anarazel.de
      Backpatch: 14-, where the refactoring commit appears.
      61a86ed5
    • Tom Lane's avatar
      Fix variable lifespan in ExecInitCoerceToDomain(). · 16a56774
      Tom Lane authored
      This undoes a mistake in 1ec7679f: domainval and domainnull were
      meant to live across loop iterations, but they were incorrectly
      moved inside the loop.  The effect was only to emit useless extra
      EEOP_MAKE_READONLY steps, so it's not a big deal; nonetheless,
      back-patch to v13 where the mistake was introduced.
      
      Ranier Vilela
      
      Discussion: https://postgr.es/m/CAEudQAqXuhbkaAp-sGH6dR6Nsq7v28_0TPexHOm6FiDYqwQD-w@mail.gmail.com
      16a56774