1. 04 May, 2021 3 commits
  2. 03 May, 2021 10 commits
  3. 01 May, 2021 1 commit
  4. 30 Apr, 2021 6 commits
    • Tom Lane's avatar
      Doc: add an example of a self-referential foreign key to ddl.sgml. · e6f9539d
      Tom Lane authored
      While we've always allowed such cases, the documentation didn't
      say you could do it.
      
      Discussion: https://postgr.es/m/161969805833.690.13680986983883602407@wrigleys.postgresql.org
      e6f9539d
    • Tom Lane's avatar
      Doc: update libpq's documentation for PQfn(). · 386e64ea
      Tom Lane authored
      Mention specifically that you can't call aggregates, window functions,
      or procedures this way (the inability to call SRFs was already
      mentioned).
      
      Also, the claim that PQfn doesn't support NULL arguments or results
      has been a lie since we invented protocol 3.0.  Not sure why this
      text was never updated for that, but do it now.
      
      Discussion: https://postgr.es/m/2039442.1615317309@sss.pgh.pa.us
      386e64ea
    • Tom Lane's avatar
      Disallow calling anything but plain functions via the fastpath API. · 2efcd502
      Tom Lane authored
      Reject aggregates, window functions, and procedures.  Aggregates
      failed anyway, though with a somewhat obscure error message.
      Window functions would hit an Assert or null-pointer dereference.
      Procedures seemed to work as long as you didn't try to do
      transaction control, but (a) transaction control is sort of the
      point of a procedure, and (b) it's not entirely clear that no
      bugs lurk in that path.  Given the lack of testing of this area,
      it seems safest to be conservative in what we support.
      
      Also reject proretset functions, as the fastpath protocol can't
      support returning a set.
      
      Also remove an easily-triggered assertion that the given OID
      isn't 0; the subsequent lookups can handle that case themselves.
      
      Per report from Theodor-Arsenij Larionov-Trichkin.
      Back-patch to all supported branches.  (The procedure angle
      only applies in v11+, of course.)
      
      Discussion: https://postgr.es/m/2039442.1615317309@sss.pgh.pa.us
      2efcd502
    • Amit Kapila's avatar
      Fix the bugs in selecting the transaction for streaming. · ee4ba01d
      Amit Kapila authored
      There were two problems:
      a. We were always selecting the next available txn instead of selecting it
      when it is larger than the previous transaction.
      b. We were selecting the transactions which haven't made any changes to
      the database (base snapshot is not set). Later it was hitting an Assert
      because we don't decode such transactions and the changes in txn remain as
      it is. It is better not to choose such transactions for streaming in the
      first place.
      
      Reported-by: Haiying Tang
      Author: Dilip Kumar
      Reviewed-by: Amit Kapila
      Discussion: https://postgr.es/m/OS0PR01MB61133B94E63177040F7ECDA1FB429@OS0PR01MB6113.jpnprd01.prod.outlook.com
      ee4ba01d
    • David Rowley's avatar
      Adjust EXPLAIN output for parallel Result Cache plans · 3c80e96d
      David Rowley authored
      Here we adjust the EXPLAIN ANALYZE output for Result Cache so that we
      don't show any Result Cache stats for parallel workers who don't
      contribute anything to Result Cache plan nodes.
      
      I originally had ideas that workers who don't help could still have their
      Result Cache stats displayed.  The idea with that was so that I could
      write some parallel Result Cache regression tests that show the EXPLAIN
      ANALYZE output.  However, I realized a little too late that such tests
      would just not be possible to have run in a stable way on the buildfarm.
      
      With that knowledge, before 9eacee2e went in, I had removed all of the
      tests that were showing the EXPLAIN ANALYZE output of a parallel Result
      Cache plan, however, I forgot to put back the code that adjusts the
      EXPLAIN output to hide the Result Cache stats for parallel workers who
      were not fast enough to help out before query execution was over. All
      other nodes behave this way and so should Result Cache.
      
      Additionally, with this change, it now seems safe enough to remove the SET
      force_parallel_mode = off that I had added to the regression tests.
      
      Also, perform some cleanup in the partition_prune tests. I had adjusted
      the explain_parallel_append() function to sanitize the Result Cache
      EXPLAIN ANALYZE output.  However, since I didn't actually include any
      parallel Result Cache tests that show their EXPLAIN ANALYZE output, that
      code does nothing and can be removed.
      
      In passing, move the setting of memPeakKb into the scope where it's used.
      
      Reported-by: Amit Khandekar
      Author: David Rowley, Amit Khandekar
      Discussion: https://postgr.es/m/CAJ3gD9d8SkfY95GpM1zmsOtX2-Ogx5q-WLsf8f0ykEb0hCRK3w@mail.gmail.com
      3c80e96d
    • Amit Kapila's avatar
      Another try to fix the test case added by commit f5fc2f5b. · 51ef9173
      Amit Kapila authored
      As per analysis, it appears that the 'drop slot' message from the previous
      test and 'create slot' message of the new test are either missed or not
      yet delivered to the stats collector due to which we will still see the
      stats from the old slot. This can happen rarely which could be the reason
      that we are seeing some failures in the buildfarm randomly. To avoid that
      we are using a different slot name for the tests in
      test_decoding/sql/stats.sql.
      
      Reported-by: Tom Lane based on buildfarm reports
      Author: Sawada Masahiko
      Reviewed-by: Amit Kapila, Vignesh C
      Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
      51ef9173
  5. 29 Apr, 2021 6 commits
  6. 28 Apr, 2021 5 commits
    • Tom Lane's avatar
      Add heuristic incoming-message-size limits in the server. · 9626325d
      Tom Lane authored
      We had a report of confusing server behavior caused by a client bug
      that sent junk to the server: the server thought the junk was a
      very long message length and waited patiently for data that would
      never come.  We can reduce the risk of that by being less trusting
      about message lengths.
      
      For a long time, libpq has had a heuristic rule that it wouldn't
      believe large message size words, except for a small number of
      message types that are expected to be (potentially) long.  This
      provides some defense against loss of message-boundary sync and
      other corrupted-data cases.  The server does something similar,
      except that up to now it only limited the lengths of messages
      received during the connection authentication phase.  Let's
      do the same as in libpq and put restrictions on the allowed
      length of all messages, while distinguishing between message
      types that are expected to be long and those that aren't.
      
      I used a limit of 10000 bytes for non-long messages.  (libpq's
      corresponding limit is 30000 bytes, but given the asymmetry of
      the FE/BE protocol, there's no good reason why the numbers should
      be the same.)  Experimentation suggests that this is at least a
      factor of 10, maybe a factor of 100, more than we really need;
      but plenty of daylight seems desirable to avoid false positives.
      In any case we can adjust the limit based on beta-test results.
      
      For long messages, set a limit of MaxAllocSize - 1, which is the
      most that we can absorb into the StringInfo buffer that the message
      is collected in.  This just serves to make sure that a bogus message
      size is reported as such, rather than as a confusing gripe about
      not being able to enlarge a string buffer.
      
      While at it, make sure that non-mainline code paths (such as
      COPY FROM STDIN) are as paranoid as SocketBackend is, and validate
      the message type code before believing the message length.
      This provides an additional guard against getting stuck on corrupted
      input.
      
      Discussion: https://postgr.es/m/2003757.1619373089@sss.pgh.pa.us
      9626325d
    • Alvaro Herrera's avatar
      Allow a partdesc-omitting-partitions to be cached · d6b8d294
      Alvaro Herrera authored
      Makes partition descriptor acquisition faster during the transient
      period in which a partition is in the process of being detached.
      
      This also adds the restriction that only one partition can be in
      pending-detach state for a partitioned table.
      
      While at it, return find_inheritance_children() API to what it was
      before 71f4c8c6, and create a separate
      find_inheritance_children_extended() that returns detailed info about
      detached partitions.
      
      (This incidentally fixes a bug in 8aba9322 whereby a memory context
      holding a transient partdesc is reparented to a NULL PortalContext,
      leading to permanent leak of that memory.  The fix is to no longer rely
      on reparenting contexts to PortalContext.   Reported by Amit Langote.)
      
      Per gripe from Amit Langote
      Discussion: https://postgr.es/m/CA+HiwqFgpP1LxJZOBYGt9rpvTjXXkg5qG2+Xch2Z1Q7KrqZR1A@mail.gmail.com
      d6b8d294
    • Tom Lane's avatar
      Doc: fix discussion of how to get real Julian Dates. · c93f8f3b
      Tom Lane authored
      Somehow I'd convinced myself that rotating to UTC-12 was the way
      to do this, but upon further review, it's definitely UTC+12.
      
      Discussion: https://postgr.es/m/1197050.1619123213@sss.pgh.pa.us
      c93f8f3b
    • Michael Paquier's avatar
      Fix use-after-release issue with pg_identify_object_as_address() · f93f0b5b
      Michael Paquier authored
      Spotted by buildfarm member prion, with -DRELCACHE_FORCE_RELEASE.
      
      Introduced in f7aab36d.
      
      Discussion: https://postgr.es/m/2759018.1619577848@sss.pgh.pa.us
      Backpatch-through: 9.6
      f93f0b5b
    • Michael Paquier's avatar
      Fix pg_identify_object_as_address() with event triggers · f7aab36d
      Michael Paquier authored
      Attempting to use this function with event triggers failed, as, since
      its introduction in a6762014, this code has never associated an object
      name with event triggers.  This addresses the failure by adding the
      event trigger name to the set defining its object address.
      
      Note that regression tests are added within event_trigger and not
      object_address to avoid issues with concurrent connections in parallel
      schedules.
      
      Author: Joel Jacobson
      Discussion: https://postgr.es/m/3c905e77-a026-46ae-8835-c3f6cd1d24c8@www.fastmail.com
      Backpatch-through: 9.6
      f7aab36d
  7. 27 Apr, 2021 5 commits
    • Andrew Dunstan's avatar
      Improve logic in PostgresVersion.pm · fa26eba2
      Andrew Dunstan authored
      Handle the situation where perl swaps the order of operands of
      the comparison operator. See `perldoc overload` for details:
      
      The third argument is set to TRUE if (and only if) the two
      operands have been swapped. Perl may do this to ensure that the
      first argument ($self) is an object implementing the overloaded
      operation, in line with general object calling conventions.
      fa26eba2
    • Fujii Masao's avatar
      doc: Review for "Allow TRUNCATE command to truncate foreign tables". · 0c8f4086
      Fujii Masao authored
      Typos, corrections and language improvements in the docs.
      
      Author: Justin Pryzby, Fujii Masao
      Reviewed-by: Bharath Rupireddy, Justin Pryzby, Fujii Masao
      Discussion: https://postgr.es/m/20210411041658.GB14564@telsasoft.com
      0c8f4086
    • Fujii Masao's avatar
      Don't pass "ONLY" options specified in TRUNCATE to foreign data wrapper. · 8e9ea08b
      Fujii Masao authored
      Commit 8ff1c946 allowed TRUNCATE command to truncate foreign tables.
      Previously the information about "ONLY" options specified in TRUNCATE
      command were passed to the foreign data wrapper. Then postgres_fdw
      constructed the TRUNCATE command to issue the remote server and
      included "ONLY" options in it based on the passed information.
      
      On the other hand, "ONLY" options specified in SELECT, UPDATE or DELETE
      have no effect when accessing or modifying the remote table, i.e.,
      are not passed to the foreign data wrapper. So it's inconsistent to
      make only TRUNCATE command pass the "ONLY" options to the foreign data
      wrapper. Therefore this commit changes the TRUNCATE command so that
      it doesn't pass the "ONLY" options to the foreign data wrapper,
      for the consistency with other statements. Also this commit changes
      postgres_fdw so that it always doesn't include "ONLY" options in
      the TRUNCATE command that it constructs.
      
      Author: Fujii Masao
      Reviewed-by: Bharath Rupireddy, Kyotaro Horiguchi, Justin Pryzby, Zhihong Yu
      Discussion: https://postgr.es/m/551ed8c1-f531-818b-664a-2cecdab99cd8@oss.nttdata.com
      8e9ea08b
    • Amit Kapila's avatar
      Use HTAB for replication slot statistics. · 3fa17d37
      Amit Kapila authored
      Previously, we used to use the array of size max_replication_slots to
      store stats for replication slots. But that had two problems in the cases
      where a message for dropping a slot gets lost: 1) the stats for the new
      slot are not recorded if the array is full and 2) writing beyond the end
      of the array if the user reduces the max_replication_slots.
      
      This commit uses HTAB for replication slot statistics, resolving both
      problems. Now, pgstat_vacuum_stat() search for all the dead replication
      slots in stats hashtable and tell the collector to remove them. To avoid
      showing the stats for the already-dropped slots, pg_stat_replication_slots
      view searches slot stats by the slot name taken from pg_replication_slots.
      
      Also, we send a message for creating a slot at slot creation, initializing
      the stats. This reduces the possibility that the stats are accumulated
      into the old slot stats when a message for dropping a slot gets lost.
      
      Reported-by: Andres Freund
      Author: Sawada Masahiko, test case by Vignesh C
      Reviewed-by: Amit Kapila, Vignesh C, Dilip Kumar
      Discussion: https://postgr.es/m/20210319185247.ldebgpdaxsowiflw@alap3.anarazel.de
      3fa17d37
    • Amit Kapila's avatar
      Fix Logical Replication of Truncate in synchronous commit mode. · e7eea52b
      Amit Kapila authored
      The Truncate operation acquires an exclusive lock on the target relation
      and indexes. It then waits for logical replication of the operation to
      finish at commit. Now because we are acquiring the shared lock on the
      target index to get index attributes in pgoutput while sending the
      changes for the Truncate operation, it leads to a deadlock.
      
      Actually, we don't need to acquire a lock on the target index as we build
      the cache entry using a historic snapshot and all the later changes are
      absorbed while decoding WAL. So, we wrote a special purpose function for
      logical replication to get a bitmap of replica identity attribute numbers
      where we get that information without locking the target index.
      
      We decided not to backpatch this as there doesn't seem to be any field
      complaint about this issue since it was introduced in commit 5dfd1e5a in
      v11.
      
      Reported-by: Haiying Tang
      Author: Takamichi Osumi, test case by Li Japin
      Reviewed-by: Amit Kapila, Ajin Cherian
      Discussion: https://postgr.es/m/OS0PR01MB6113C2499C7DC70EE55ADB82FB759@OS0PR01MB6113.jpnprd01.prod.outlook.com
      e7eea52b
  8. 26 Apr, 2021 4 commits
    • Alvaro Herrera's avatar
    • Tom Lane's avatar
      Remove rewriteTargetListIU's expansion of view targetlists in UPDATE. · 04942bff
      Tom Lane authored
      Commit 2ec993a7, which added triggers on views, modified the rewriter
      to add dummy entries like "SET x = x" for all columns that weren't
      actually being updated by the user in any UPDATE directed at a view.
      That was needed at the time to produce a complete "NEW" row to pass
      to the trigger.  Later it was found to cause problems for ordinary
      updatable views, so commit cab5dc5d restricted it to happen only for
      trigger-updatable views.  But in the wake of commit 86dc9005, we
      really don't need it at all.  nodeModifyTable.c populates the trigger
      "OLD" row from the whole-row variable that is generated for the view,
      and then it computes the "NEW" row using that old row and the UPDATE
      targetlist.  So there is no need for the UPDATE tlist to have dummy
      entries, any more than it needs them for regular tables or other
      types of views.
      
      (The comments for rewriteTargetListIU suggest that we must do this
      for correct expansion of NEW references in rules, but I now think
      that that was just lazy comment editing in 2ec993a7.  If we didn't
      need it for rules on views before there were triggers, we don't need
      it after that.)
      
      This essentially propagates 86dc9005's decision that we don't need
      dummy column updates into the view case.  Aside from making the
      different cases more uniform and hence possibly forestalling future
      bugs, it ought to save a little bit of rewriter/planner effort.
      
      Discussion: https://postgr.es/m/2181213.1619397634@sss.pgh.pa.us
      04942bff
    • Tom Lane's avatar
      Doc: document EXTRACT(JULIAN ...), improve Julian Date explanation. · 79a5928e
      Tom Lane authored
      For some reason, the "julian" option for extract()/date_part() has
      never gotten listed in the manual.  Also, while Appendix B mentioned
      in passing that we don't conform to the usual astronomical definition
      that a Julian date starts at noon UTC, it was kind of vague about what
      we do instead.  Clarify that, and add an example showing how to get
      the astronomical definition if you want it.
      
      It's been like this for ages, so back-patch to all supported branches.
      
      Discussion: https://postgr.es/m/1197050.1619123213@sss.pgh.pa.us
      79a5928e
    • Peter Eisentraut's avatar
      Fix pg_upgrade test on Cygwin · 38c9a593
      Peter Eisentraut authored
      The verification of permissions doesn't succeed on Cygwin, because the
      required feature is not implemented for Cygwin at the moment.  So skip
      this part of the test, like MinGW already does.
      38c9a593