1. 14 Jun, 2020 1 commit
    • Michael Paquier's avatar
      Replace superuser check by ACLs for replication origin functions · cc072641
      Michael Paquier authored
      This patch removes the hardcoded check for superuser privileges when
      executing replication origin functions.  Instead, execution is revoked
      from public, meaning that those functions can be executed by a superuser
      and that access to them can be granted.
      
      Author: Martín Marqués
      Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Masahiko Sawada
      Discussion: https:/postgr.es/m/CAPdiE1xJMZOKQL3dgHMUrPqysZkgwzSMXETfKkHYnBAB7-0VRQ@mail.gmail.com
      cc072641
  2. 13 Jun, 2020 8 commits
  3. 12 Jun, 2020 4 commits
    • David Rowley's avatar
      Add missing extern keyword for a couple of numutils functions · 9a7fccd9
      David Rowley authored
      In passing, also remove a few surplus empty lines from pg_ltoa and
      pg_ulltoa_n in numutils.c
      
      Reported-by: Andrew Gierth
      Discussion: https://postgr.es/m/87y2ou3xuh.fsf@news-spur.riddles.org.uk
      Backpatch-through: 13, where these changes were introduced
      9a7fccd9
    • Tom Lane's avatar
      Avoid using a cursor in plpgsql's RETURN QUERY statement. · 2f48ede0
      Tom Lane authored
      plpgsql has always executed the query given in a RETURN QUERY command
      by opening it as a cursor and then fetching a few rows at a time,
      which it turns around and dumps into the function's result tuplestore.
      The point of this was to keep from blowing out memory with an oversized
      SPITupleTable result (note that while a tuplestore can spill tuples
      to disk, SPITupleTable cannot).  However, it's rather inefficient, both
      because of extra data copying and because of executor entry/exit
      overhead.  In recent versions, a new performance problem has emerged:
      use of a cursor prevents use of a parallel plan for the executed query.
      
      We can improve matters by skipping use of a cursor and having the
      executor push result tuples directly into the function's result
      tuplestore.  However, a moderate amount of new infrastructure is needed
      to make that idea work:
      
      * We can use the existing tstoreReceiver.c DestReceiver code to funnel
      executor output to the tuplestore, but it has to be extended to support
      plpgsql's requirement for possibly applying a tuple conversion map.
      
      * SPI needs to be extended to allow use of a caller-supplied
      DestReceiver instead of its usual receiver that puts tuples into
      a SPITupleTable.  Two new API calls are needed to handle both the
      RETURN QUERY and RETURN QUERY EXECUTE cases.
      
      I also felt that I didn't want these new API calls to use the legacy
      method of specifying query parameter values with "char" null flags
      (the old ' '/'n' convention); rather they should accept ParamListInfo
      objects containing the parameter type and value info.  This required
      a bit of additional new infrastructure since we didn't yet have any
      parse analysis callback that would interpret $N parameter symbols
      according to type data supplied in a ParamListInfo.  There seems to be
      no harm in letting makeParamList install that callback by default,
      rather than leaving a new ParamListInfo's parserSetup hook as NULL.
      (Indeed, as of HEAD, I couldn't find anyplace that was using the
      parserSetup field at all; plpgsql was using parserSetupArg for its
      own purposes, but parserSetup seemed to be write-only.)
      
      We can actually get plpgsql out of the business of using legacy null
      flags altogether, and using ParamListInfo instead of its ad-hoc
      PreparedParamsData structure; but this requires inventing one more
      SPI API call that can replace SPI_cursor_open_with_args.  That seems
      worth doing, though.
      
      SPI_execute_with_args and SPI_cursor_open_with_args are now unused
      anywhere in the core PG distribution.  Perhaps someday we could
      deprecate/remove them.  But cleaning up the crufty bits of the SPI
      API is a task for a different patch.
      
      Per bug #16040 from Jeremy Smith.  This is unfortunately too invasive to
      consider back-patching.  Patch by me; thanks to Hamid Akhtar for review.
      
      Discussion: https://postgr.es/m/16040-eaacad11fecfb198@postgresql.org
      2f48ede0
    • Michael Paquier's avatar
      aaf8c990
    • Peter Eisentraut's avatar
      Make more use of RELKIND_HAS_STORAGE() · ffd25822
      Peter Eisentraut authored
      Make use of RELKIND_HAS_STORAGE() where appropriate, instead of
      listing out the relkinds individually.  No behavior change intended.
      Reviewed-by: default avatarTom Lane <tgl@sss.pgh.pa.us>
      Discussion: https://www.postgresql.org/message-id/flat/7a22bf51-2480-d999-1794-191ba67ff47c%402ndquadrant.com
      ffd25822
  4. 11 Jun, 2020 12 commits
  5. 10 Jun, 2020 4 commits
  6. 09 Jun, 2020 6 commits
  7. 08 Jun, 2020 5 commits